Notices by Steve Bate (steve@social.technoetic.com), page 4

@helge @hrefna Rephrasing the question as "Why does ActivityPub not define a concept of ownership?" may be better. The other issue with the vague reference to "owned by the server" is that "server" is not defined anywhere. What defines the scope of server ownership? Maybe a URL prefix (to support multi-tenant implementations)? Or attribution to an "application actor" (or "tenant actor")? It's definitely an underspecified topic.

One of the challenges with #ActivityPub targeting is that the targeting properties (to, cc, bto, bcc, and maybe audience) conflate inbox delivery, interaction authorization, notification policies, and visibility (and probably more). This is a broad range of somewhat orthogonal behaviors and the limited guidance in the specs for them only makes it more challenging for AP devs.

This looks *very* interesting. The goal of ActivityPods 2.0 is Mastodon-compatible integration of #ActivityPub with Solid Pods. They call it Mastopods.
https://activitypods.org/blog/the-road-to-activitypods-2-0/

@silverpill I'm not comfortable with the "hosts=" approach either because the full URI still depends on domain names.

@pfefferle Some related information about the `context` property:

FEP-7888: Demystifying the context property
https://codeberg.org/fediverse/fep/src/branch/main/fep/7888/fep-7888.md

Activity Streams Extensions Primer (context used in examples)
https://www.w3.org/wiki/Activity_Streams/Primer/Extensions

Is anybody aware of the #ActivityPub actor “streams” property being used in an implementation?

@evan ok, I'll do that and delete the related post.

@evan The link showed up in Google search results for "activitypub internet of things". I saw there were discussions in the comments so I assumed it had been released publicly elsewhere. If you don't want it shared I can delete the post and the link from my bookmarks collection.

@evan @jasnell Thanks. It looks like they are included in the JSON-LD expansion, but not when converting to RDF (unless declared at "@list", which makes sense). I just checked, and the JSON-LD 1.0 specification states that an array "is represented as square brackets surrounding zero or more values", so an empty array appears valid (same for 1.1). That's why I was curious about the rationale for the AS2 specification having the additional constraint. (context: working on AS2 validator code)

@evan @jasnell Why are empty arrays not allowed in Activity Streams 2.0?

Have you ever wondered how #ActivityPub got its name and what other names were considered? Here's the transcript from the W3C meeting where the naming happened. https://www.w3.org/wiki/Socialwg/2016-01-12-minutes

I wanted to be able to search and browse the #ActivityPub Fediverse Enhancement Proposals (FEPs) so I converted them to an Obsidian vault. As a nice side-benefit, I can now view the graph of FEP dependencies and their color-coded status (green=FINAL, yellow=DRAFT, red=WITHDRAWN).

@atomicpoet How would you determine "Hot", "Top", "Rising"? Mastodon, and probably other implementations, don't federate likes. That may be true for reply counts too.

@evan The AP extension update is very nice! I'm accustomed to only seeing a few AS2 types used so this was refreshing. Are you familiar with https://castling.club/? It's an AP-enabled online chess game app but it's mostly implemented with the Note type (to be Mastodon-compatible). Your examples give me a lot to think about. Thanks!

@evan I like the priorityInbox example. Those objects would still need the OrderedCollection "type" property, right?

Now that I've learned reverse chrono is not a blanket requirement for AP OrderedCollection, it opens up many possibilities (and makes more sense, in general).

@evan I was thinking all AP OrderedCollections have the reverse chrono ordering restriction because Section 5 states “An OrderedCollection MUST be presented consistently in reverse chronological order.” This is in the general context of collections rather than specifically for the inbox or outbox.

@evan However, I didn’t understand your statement about all properties in any AP document. I am thinking the reverse chrono ordering applies to Object ordering in an OrderedCollection. The property or properties used for sorting keys aren’t specified. Also from Section 5, “What property is used to determine the reverse chronological order is intentionally left as an implementation detail.”

@evan Maybe so. So AP only requires the reverse chrono ordering for OrderedCollections used specifically for the inbox and outbox? Maybe I did misread that. I’ll go back and review it. Thanks for the clarification.

@evan Yes, I agree. It would be more important when reading a collection. I’m sorry that I wasn’t communicating clearly.

Your family list example is interesting. Given the AP reverse chrono ordering restriction on OrderedCollection, it seems like a different subtype of ordered Collection would be needed to return an alphabetically sorted collection.

@evan I mentioned the sender in the context of the inbox filtering/routing (and maybe for the outbox in C2S?). This is similar to what you described for pump.io. It's a good question related to the ordering criteria. The collection consumer (vs the sender) might not care *how* a collection is ordered, just that it is.