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

@evan I understand. That's why I said repeatedly that I'm not discussing serialization. I agree that serializing Collections with embedded copies of Objects is needed for interoperability with most existing AP S2S implementations. To clarify, are you concerned about statements related to valid, allowed AP (serialized) representations that aren't the ones typically implemented? Versus invalid representations?

@evan I'm open to style suggestions. However, I still think my original statements are true. I've tried to explain why, but if you have questions, let me know.

@evan One can discuss containment without identifying the *real* location of objects (whatever that even means). You seem to be annoyed with this discussion, so I'm going to end my part in the thread now. However, I think it's important (and maybe I'm the only one that feels this way?) to discuss and fully understand these and other confusing aspects of AP/AS2, so don't be surprised to see related posts in the future.

@evan Not necessarily. If you'd like, I can quickly write a simple AP-server that will return a JSON-serialized inbox Collection with URIs in the "orderedItems" array instead of embedded serialized copies of the object referents. It won't interoperate with typical server implementations (Vocata is one exception), although AFAIK it would be conformant with AP/AS2. But again, this is conflating serialization with whatever abstract data model underlies it.

@evan I understand the extension goal, but how does that work without using JSON-LD processing to expand (disambiguate) terms? In other words, how is extensibility supposed to work for developers using plain JSON?

@evan I think we're conflating data models with JSON(-LD) *serialization* of those models and that's going to cause even more confusion. Without RDF, I think it's not going to be easy to discuss whatever abstract data model AP uses.

I'm still not clear about the discussion we had yesterday. @evan are AS2 (and #ActivityPub) serializations JSON-LD or not? I see the AS2 spec says the serialization only has "“compatibility with JSON-LD” but must conform to JSON-LD algorithm requirements. I understand if it's JSON-LD, it is also JSON (but not necessarily the inverse). Like we discussed yesterday, JSON-LD is JSON and it's an RDF data model. JSON, in general, is neither JSON-LD nor an RDF data model.

@evan Yes, this would be for ActivityPub 2.0, if that ever happens.

@evan To be clear, I'm not saying Mastodon per se is broken wrt Updates. I'm saying change tracking is problematic in the AP recommendation. An Object URI will always reference the latest state of the Object, not the previous states for previous Updates (all referring to the same `object` URI). The Update could have had the changes as the Activity `object` and the target URI to update as, well, the `target`. Then the history of changes could have been preserved.

@evan Yes, I acknowledged there are ways to work around it, some more "elegant" than others. Some servers, like Mastodon, don't have an inbox collection and don't store Activities (like old Update activities that would be effectively mutated by new ones when an Object is modified). They effectively just store the Objects and overwrite the data when the Objects are updated (and then synthesize new Create Activities on-demand for the pseudo-outbox).

@evan I see *numerous* discussions about RDF in the transcripts from AS2 SocialWG meetings c. 2014-2015 and I see at least one tracked issue that references the discussions. Yes, AS1 used JSON. However, AS2 uses JSON-LD. Per the JSON-LD spec, "a JSON-LD document is both an RDF document and a JSON document and correspondingly represents an instance of an RDF data model." Based on that, isn't AS2 (and therefore AP) data literally an RDF data model? 🤔 https://www.w3.org/Social/track/issues/21

@naturzukunft@mastodon.socia Yes, I think the Update part of ActivityPub is effectively broken and should be fixed someday. That said, I understand why it wasn't covered well back then. It's a very complicated topic and they seemed to want to downplay the AP/AS2 RDF foundations. Fortunately, there are ways implementations can "work around" the issues.

@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.

@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).

"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.

@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.

@J12t @evan I must be missing something. I see 85 open issues on the page you linked.