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

@silverpill AFAIK, AP doesn’t define any type-specific Update side-effects (actor vs non-actor).

For standard AS2 actor types, neither inbox nor outbox are needed for detection. For inferring AP actor extension types, I think the FEP should be conformant with the AP spec.

@silverpill @naturzukunft @julian @evanprodromou I agree “transient” not clear at all. The
errata you’re referring to is for C2S Partial Updates (Section 6.3.1) rather than anonymous objects, right?

@silverpill @mariusor I believe that removing the Actor type from the AS2 specification was a mistake (especially after looking at the rationale behind it).

That said, I'm not sure that "core type" is a meaningful label.

@silverpill You allow a missing outbox in your FEP although it's required by AP. I think inbox should also be optional. For S2S, if a server has a sharedInbox, the actor-specific inbox endpoint is not very useful. A shared inbox endpoint plus activity/object targeting properties is enough. For duck typing, an "Actor" is a thing that performs an Activity: it's the object (in an RDF sense) of some Activity `actor` relationship.

@silverpill @naturzukunft @julian The AP spec conflates the "anonymous object" and "transient object" concepts. To be precise, an anon object explicitly has a JSON `null` for an id rather than not having an id property at all. (In JSON-LD, it's the same thing, but.... AP should primarily be interpreted as JSON, per @evanprodromou). I've seen very few anonymous objects in the wild (given that definition).

The "Social Web" (#ActivityPub) Foundation's support from Meta and their links to Meta and X are even more dubious after Zuck's policy announcement. I think they should remove the links (and the associated accounts).

I've been developing an #ActivityPub C2S-based (with extensions) API facade/proxy proof-of-concept for Mastodon. It runs as a separate process that supports proxying the Masto operations but also adds a postable C2S outbox with support for AP C2S activities. These activities are converted into upstream Mastodon API calls. This extended C2S API also supports search, streaming events, managing bookmark collections, and retrieving timeline collections. 1/2

I submitted a draft FEP describing the Mastodon and LitePub/Pleroma #ActivityPub relay protocols. Comments and corrections are welcome.

https://codeberg.org/fediverse/fep/src/branch/main/fep/ae0c/fep-ae0c.md

@silverpill Is there a script for checking a new FEP before submitting a PR? (For content and metadata issues, for example)

Does anybody know which #ActivityPub relay implementation is the most widely deployed?

Mastodon doesn't implement the #ActivityPub "API" (C2S). They don't conform to either the client or server profiles in the AP Recommendation. They implement a very small subset of AP/AS2 and they don't conform to the AS2 Recommendation for the parts they implement. Their software supports > 80% of the MAU in the Fediverse (all protocols, not the SWF definition). And Evan uses this as evidence of ActivityPub's success? I think Mastodon has thrived despite ActivityPub problems, not because of it.

"The inbox stream contains all activities received by the actor." (#ActivityPub Rec). However, AP/AS2 collections (including "special" ones like Inbox, Outbox, Followers, etc.) do not contain Objects or Activities. They contain URI *references*. That's why one Create/Note can be referenced by many inboxes. It may look like Collections contain Objects because of typical server JSON-LD serialization, but don't be fooled. It makes a difference for data lifecycle management and storage models.

@evan How does work in RDF? Again, I'm talking about the underlying model, not the way it is serialized to JSON-LD for network communication. I'm also not discussing local caching/copying of remote AP/AS2 Objects (a different, but interesting topic).

@jonny @evan Very true for RDF, in general. However, in an ActivityPub context (at least, as specified) identity and location are somewhat tightly coupled. Although not AP per se, some aspects of the typical authorization implementations also rely on it. There are grassroots efforts with the goal of separating identity and location in AP, but it's still in the early stages.

@silverpill I agree it probably won't happen, but I can dream. One concern I have about the FEP you reference is that it contains opinions that are debatable (and have been debated on SocialHub and elsewhere). It should maybe be called "An Opinionated List of Reasonable ActivityPub Development Suggestions." (a little long, I know 😉 ). It might help if the FEP recommendations were tagged as spec clarifications versus extended practices (like with at least some of the duck typing suggestions).

I believe the W3C should reconsider splitting the #ActivityPub Recommendation into three documents: Core/Shared requirements, S2S (Server-to-Server, "social/federation protocol"), and C2S (Client-to-Server, "social API"). I think it would reduce developer confusion and help them focus on requirements that are relevant to their work (typically, S2S/Core). It would also allow C2S to be improved independently so that more developers might consider using it.

@silverpill @smallcircles @steve @zicklag That’s an odd comparison, between a so-called protocol and a markup language. In any case, I’d claim HTML is *far* better specified than ActivityPub.

@silverpill @smallcircles @zicklag

>> But ActivityPub is also largely underspecified

> ActivityPub is not underspecified. … It is a protocol for building all kinds of decentralized social applications.

Which results in it being underspecified for any specific application (especially if interop is a goal). But it’s an interesting spin. ;-) As others have noted over the years, #ActivityPub more of a sketch or outline of an idea than a protocol.

@blog Yes, it’s a shame that Fedi public keys for HTTP signatures are not publicly accessible in authorized fetch scenarios. That doesn’t make much sense to me. The reason for it (fragment-based key IDs in Mastodon) is obscure and seems arbitrary to me. The fix is relatively easy, but I don’t see much motivation to fix it.

I’m beginning to wonder if the email mental model some people suggest for #ActivityPub is a serious hindrance to understanding the concept of a federated, decentralized social graph.