@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.
> 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.
@andypiper Overall, it's a very nice video. I just wish the creator hadn't compared the Fediverse to the United States. There's nothing analogous to the US Federal Government in the Fediverse. Since the USA wouldn't function well without the Federal Government (I'm sure opinions will vary), the point isn't clear to me. Said differently, "federated" can have different meanings in different contexts (nations vs software servers) and I think this video conflated multiple meanings of the word.
@andypiper A better analogy might be the international postal system (snail mail) that is federated and is generally effective without central governance.
The list is longer than that, but it would need a long form post to cover all of what would be needed to have something similar to the Mastodon UX. This is easy to confirm if you compare the APIs.
It's possible to implement some of those features in a ad hoc way using AS2 data structures, but I believe many UI developers prefer an API that's standardized across server implementations.
@mariusor@jenniferplusplus@benpate I apologize that my response to your replies were hurtful. I actually felt like you were being a little dismissive about the larger issue of C2S deficiencies relative to the Mastodon API (and why C2S is not widely used) and that you were challenging me to defend my position on that issue. Showcasing experiments with C2S UIs would be a great topic for a different discussion thread. (I plan to dig into your implementation further when I have time.)
@mariusor@jenniferplusplus@benpate Yes, I wish it were, but I do believe AP C2S should not under consideration for most UI applications (based on my own experience with it). Because I’d really like it to be more feature-complete, I may respond strongly when someone suggests it’s already good enough. I don’t know what it would take to make it viable for most applications (where “viable” means about the same UX as current popular Mastodon UIs).
@benpate@dansup I believe the primary reason there are no widely-used C2S user-facing clients (vs testing tools) is that the standard C2S API is not sufficient for a decent UX. If you compare the Mastodon client API with the AP C2S API, there's a significant disparity in features.
@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.
American living in Southern France. Developer of the FIRM server platform. I'm interested in #computers, #SoftwareDevelopment, #SemanticWeb, #osint, #DistributedComputing, #pkm, #HomeAutomation, #PhysicalComputing, #iot, #rpi, #esp32, #hiking, #traveling, learning #french and lots of other stuff.