idk where to really put this (might turn into a blog post later or something). it’s what you might call a “hot take”, certainly a heterodox one to some parts of the broader #fediverse community. this is in response to recent discussion on “what do you want to see from AP/AS2 specs” (in context of wg rechartering) mostly devolving into people complaining about JSON-LD and extensibility, some even about namespacing in general (there was a suggestion to use UUID vocab terms. i’m not joking)
1/?
@[email protected] you should definitely use a blog :)
Yeah, not going to read 30+ comments deep. IMO OP tossed their own efforts in the trash putting it out there this way.
@[email protected] managing blogs is so annoying though :(
@[email protected] Thanks for the thread! Coming myself from a linked data background and having adopted a simple use of JSON-LD as Linked Open Usable Data (LOUD), I never understood (and still don’t understand) what problems people have with JSON-LD in AP and AS. I am much in favour of an open world approach. It is quite powerful if people share their extensions and try to find and reuse solutions by others. In the end, we’d create shared data models together: a social act for the social web.
@[email protected] the core of the complaint is that people want to handle one key and one key only. they don’t want to map terms to IRIs, or IRIs to terms. they’d prefer picking exactly one symbol and use that as the property key.
@[email protected] And I always thought that this is some of the LD patterns that easily make sense: to globally identify each term used in your data by an IRI and to use the same IRI as a link to the term’s documentation. Apparently, I was wrong.
OTOH, I get it when people don’t think they need (to understand) JSON-LD but I also think it is not too much to ask to follow community patterns by slapping a context link into your JSON.
@trwnh 1.) love this, looking forward to the blog post. 2.) i’m not 100% convinced of the analogy of open-world : closed world :: AP : “one” “social” “network” , but it resonates a lot with my thinking on platforms lately. i think the fediverse thinks of itself as ONE OPEN platform, rather than multiple overlapping platforms (that could include closed platforms, too, in every sense of closed including the economic!) with no global guarantees, periodt.
@[email protected] yeah i’m not saying AP is “open-world” but rather it straddles the line
AS2 requiring the AS2 context is a bit weird from an LD perspective because it introduces weird “supremacy” conflicts especially with the “MUST NOT override” requirement
i’ve thought that perhaps jsonld context should only ever be a “progressive enhancement” to json, and that new apis or interchange formats should instead use expanded form, and processors should expand any compacted json(ld) before using it
@trwnh oh interesting i didn’t realize that you meant openworld/closedwforld that literally in the RDF sense, i thought you meant more in the protocol-design sense (of like “drop all unfamiliar properties” as is conventional for all JSON protocols versus “here is how you cautiously parse or preserve for others what you don’t know”)
@[email protected] but that’s a difference without a distinction, perhaps
the main contention is a disconnect between #ActivityPub as a spec and #fediverse as a protocol/network. a lot of problems cited were with the fediverse as implemented, wishful thinking about what could be changed in spec, many backwards-incompatible, mostly in service of making fediverse impl less painful.
there is a recurring refrain about implementers deciding they don’t care to implement AP as specified, and that this indicates a problem with the spec, not a problem with implementers.
2/?
i think this disconnect between #ActivityPub and #fediverse honestly goes a lot deeper than people might realize. and that is because the problem AP tries to solve is actually completely different from what fedi is trying to do.
the concept of a nebulous but mostly singular “network” or “protocol” (made up of partially overlapping parts) is core to what i’ll call “fedi mindset”. the assumption is that you can join the fedi “network” by implementing the fedi “protocol”. and that AP is this.
3/?
but this assumption starts to break down when you look a little closer.
first, consider #ActivityPub C2S. why is there close to zero usage of this in #fediverse software? simple: it doesn’t solve any needs for building a “network” “protocol”.
now consider S2S. why are there zero compliant impls in fedi? because AP as specified doesn’t address the needs of fedi. what does fedi need? well, i find it telling that the “real” reason AP was adopted was… to implement followers-only posts.
4/?
which is to say: the primary reason that #ActivityPub is used (to the extent you can say it is being used at all) in the #fediverse is mostly historical.
fedi grew out of a long line of open protocols, and before AP was adopted, it was at the point where people primarily used “activity streams” as their vocabulary and data model, stuffed into atom feeds. atom feeds don’t do private posts unless you make an entirely new access-controlled feed, possibly with a token of some sort. hence, AS2.
5/?
when #ActivityPub was being standardized alongside AS2 it basically had two compelling reasons for what would become the #fediverse to adopt it:
-
it was built on AS2, which was an evolution of AS1, which was already being used. so it wasn’t hard to make the jump.
-
it made followers-only posts possible, because while atom feeds could do this, it was wildly inconvenient to actually do it that way. posting something private to an inbox is a lot simpler, no juggling access control tokens.
6/?
but beyond that, what does #ActivityPub actually do for #fediverse as a “network” “protocol”? basically nothing. you have a basic mechanism for delivering activities directly to subscribers, but no specified shape or structure for that payload. and you still need a lot of other specs to end up with something that talks to the “network”. even with AS2 vocab, you need more vocab extensions to express things you want to.
simply put, AP is not enough for a “protocol” to build a “network”.
7/?
but before you build a “protocol” for a “network”, consider: what even is a “network”, in this context? and, here’s the hot take: do you even want that kind of “network”? do you want a separate reified #fediverse network?
because the answer that #ActivityPub gives is actually a different one. There is no “AP network”, because AP as a protocol is not enough to build a concrete network. it is intended to provide, and exists in context of, the larger #Web.
8/?
this is the fundamental divide between #fediverse thinking and #Web thinking, where #ActivityPub straddles the line between both.
i’ve seen it said that the “open-world assumption” at the foundation of the Web is actually an undesirable thing for a “social networking protocol”, and as a consequence, specs built on that open-world assumption are “completely unsuitable” for that “protocol”.
but do we need a “social networking protocol”? do we even need “social networks” in the first place?
9/?
@[email protected] This is related to my recent-ish realization (which I always knew on some level but never formulated explicitly) that AP simply does not have much to say about the mechanics of federation. And that there is basically nowhere that federation is defined; it is pretty much left as an implementation detail for the author of a server to figure out
-
