|
Top-level
 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/? 74 comments
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/?  @thisismissem needing to be social online =/= needing social networks as a paradigm. i'll address this in a later post in the thread (getting there!) to build the #fediverse as its own "social networking protocol" then seemingly requires that we instead go with the closed-world assumption, contrary to the #Web it requires ahead-of-time communication and coordination, where implementers need to be willing and available to talk to any other implementer, and this load grows with every new implementer. it requires you to be aware of other extensions, present and future, because your extension might conflict with someone else's extension. 10/? the way extensibility works in a closed-world #fediverse is that "every implementer talks to every other implementer". or maybe there is a central registry of extensions that everyone submits to their authority, as stewards of the "protocol" that is used to build the "network". this trades out the n:n relation between implementers and other implementers, for an n:1 relation between implementers and the central registry. the way extensibility works in an open-world #Web is you just do it. 11/? the challenge in closed-world systems is how to scale communication and coordination as the number of implementers grows. without a central authority, it almost inevitably leads to power coalescing in the hands of the few most popular or largest implementations, who become the "de facto" standard and get to mostly do what they want, and everyone else mostly has to follow if they want to be compatible. sound familiar? it should, because this is the model that the #fediverse follows today. 12/? indeed, the #fediverse is more closed-world than open-world. you see this in the so-called "rejection" of json-ld among presumably the majority of fedi implementations. because for the most part, AS2 lets you ignore json-ld. it only matters for extensibility, and (specific criticisms of json-ld aside) json-ld also mostly allows you to ignore it. so why do people still complain about it? well, there is the concept of "context" in json-ld, which represents shared understanding. 13/? say some random person sees the statement above. they don't know who john or sally are, and they don't know what "knows" means in this context. well, if we do a little work upfront, they actually *can* know what all of these terms mean, **without ever asking us directly** we put a resource on example.com for each of these terms, and each resource describes the subject of that identifier -- it is a "resource descriptor". the resource for knows/1 can define itself explicitly with a schema 16/? now at this point you're probably wondering what this has to do with social networking. and on a practical level, if you're just interested in building a "social networking protocol", this is mostly all extraneous. the part that implementers have to deal with is the notion of "context" and, more specifically, how json-ld handles it, and even more specifically, what to do when two shorthand terms conflict. remember, the open-world solution is namespacing. what does closed-world do? 18/? well, let's look at `actor`. in AS2 terms it refers to the entity that performed an activity. but in schema.org terms it refers to someone playing a role in a movie or other performance. in a closed-world sense, you don't want to be aware of context. you don't want to have to deal with it. but even so, you still have an "implicit context" that you are using, based on how you define each term in your own understanding, what you hardcode into your software. 19/? what json-ld does, or what it allows you to do, is explicitly declare a `@context` that is equivalent to your "implicit context". this works fine if there is only one declaration that is shared exactly between two parties, but it gets complicated when the "implicit context" differs or isn't an exact match. this means that there cannot ever be a singular #fediverse network, because the "implicit context" differs between each software project. the only guaranteed overlap is the AS2 one. 20/? now there's a few thoughts i have here: #fediverse culturally seems to ignore a lot of other things as well. they ignore http caching for example. they ignore http status codes like 301 Permanent Redirect. these requirements are arguably more important than context, and they *still* get ignored. in fact, most fedi software is mostly just reimplementing Web browsers, but with what they consider to be the "bare minimum" of compliance. and the web they let you browse is smaller than the Web 22/? are these things part of the "protocol"? how far does the "protocol" extend to cover? because, as we established, #ActivityPub is not enough to build a fully functional #fediverse -- and a lot of extensions and additional specs are things that ought to be included in this "protocol", insofar as this "protocol" is desirable. the other thought: if you ignore things, that means there are cases you're not handling, losing out on robustness. ignoring context is to ignore shared understanding. 23/? this is because #fediverse is ignoring context. the implicit context is that `discoverable` means `http://joinmastodon.org/ns#discoverable` but they don't know that. so they can't actually handle the extension in its fullest form. what AS2 calls out as "full support for extensions" requires being able to identify this equivalence and handle it. again, fedi does... let's call it "partial support". the "implicit context" is now a hardcoded but unstated requirement of this "protocol". 25/? which is to say: #fediverse software generally expects LD-aware producers to compact against their own "implicit context", but they don't always define that context. it's left undeclared and undefined. or it actually *is* declared, but if you give them their own expanded form then they'll not understand it. it's like someone saying hey, when i say "knows", i mean "is familiar with" and then you say "john is familiar with sally" and they respond WTF? what does "is familiar with" mean? 26/? it's like... you literally just told me "knows" = "is familiar with", but because of your own ignoring of your own context, you can't handle me saying "is familiar with"? in this way, as long as the #fediverse remains ignorant of context, they will remain fragile and without any sort of robustness in their "protocol". the alternative they have is to extend the only context they share, which is the AS2 one. but this doesn't solve the problem. it just officially blesses a single term. 27/? if you want to turn "activitystreams" into a "protocol" then sure i guess you can do that but why? what are the needs we're trying to address here? of what purpose is your "protocol"? social networking? you want a "social networking protocol"? before you convince people that a "social networking protocol" is necessary, you have to convince people that a "social network" is necessary. but more importantly, you are contrasting that "social networking protocol" against the "social Web". 28/? it is my personal belief that this whole "closed-world social network" vs "open-world social Web" thing is leading to a big disconnect that makes addressing people's needs harder. because, to be on the "network", you neglect being on the "Web". sure, your software might still publish your "posts" as Web resources, but that's it. you're not actually granted control or ability to manage Web resources for yourself. and that's why #ActivityPub C2S is being neglected, among many other things 29/? i am personally more in favor of a "social Web" than a "social network". what i want to do is make it easier for anyone to make a website, and to manage that website. i want those websites to be able to link to each other in well-defined and clearly-understood ways. i want to make friends and express myself to the fullest, in varying contexts on various websites, without context collapse. but it feels like #fediverse is more interested in replicating the "social network" paradigm. 30/30 addendum 31/30 there's a whole lot of things i could say about "how we get there" but the thread was getting long enough and i want to cut it off here and clean it up into a blog post or something, without drifting too far off the original topic which was to voice my thoughts about the divide itself addendum 32/30 there's a separate thought experiment you could do about what it really takes for a "social networking protocol" because honestly you don't even need http. you can do "social networking" over xmpp or email or whatever. or invent your own way to send bytes over tcp/udp/whatever (inb4 xkcd) seriously tho, newsletters and deltachat and movim and a bunch of other things show that you can do it  @trwnh nice writeup! Just glancing, so without getting into detail, I think I agree. This is perhaps my own bias in all of this, but it's interesting that one of the most-consistent aspect of Fedi implementations is their reliance on Webfinger. I worked on that part because I didn't think the data format stuff really mattered that much, and at worst was going to be stifling. It was excluded from AP for political, http fundamentalist reasons, but [imho] is essential to the networks functioning. @trwnh linking, which as you point out is key – to people – depends on regular people being able to share their names. I learned a long time ago that most people aren't good at groking the HTTP part of links, because the structure of links is actually really complex. When you mention xmpp and email, the identifier is the thing that makes both of those networks work. For me, "fedi" or "AP" or the social web or whatever we want to call it has always been about making personal identity linkable. @trwnh when the first round of "social networks" were built, the first thing that got added to the databases were a "users" and a "friends" table, because "the web" doesn't (didn't?) have that. Decentralizing that is a radical act, and the sorts of things that we can do with a linked [bi-directional] web of people is infinite and bounded only by our imaginations. AS and AP actions and data formats and C2S are, as I think you're saying, just stubs for rebuilding the old world in a new way. ❤️ @blaine yeah, the ultimate goal is letting people link with each other in the spaces that they wanna link up i think "your website" should be like your home, but also you should be able to go to other websites just as if they were "venues". so you go to the local forum to hang out. but you can still have your activity on that forum broadcasted to your followers. or alternatively you can participate in the forum from your own site, just like you can reply to a github notification email! @blaine i'm wondering to what extent fedi would implement webfinger if mastodon didn't require it i think if i had to really pick a format for identity then it would be a weak preference for FQDN, but having your id be a pretty-url is also okay i guess. but one other thing that i think would be cool is being able to find your contacts via webfinger if they choose to make themselves findable by other means! so you could do wf?resource=tel: or ?resource=mailto: and still get back useful info... @trwnh fun fact, webfinger actually supports URLs and [in theory] phone numbers! The key (and this is a social science and cultural insight, not technical) is that when you ask someone's "name" or "address" they need something that's unambiguous, personal, and opaque in the sense that it works everywhere (online / distributed, it needs to be globally unique, too) or they won't use it. Bare domains aren't ideal because (1) they're expensive and (2) management is hard. @blaine tumblr made it work so idk if it's "ideal" per se but they definitely had a cultural thing going for quite a while with "dot tumblr dot com" even being a meme at some point it can't be too hard to manage tbh, the modern version of this is atproto handle services that do nothing but allocate you a subdomain for use on bluesky @trwnh the "trick" with webfinger is that it's a way to go from a "name" to an authoritative context (the authority for "x@y.xyz"' is "y.xyz" and the authority for "blah.com" is "blah.com"; the challenge with phone numbers is that it's impossible to infer the authority for +1-416-867-5309 / telcos don't provide a lookup system). That's really it; the rest is a cultural thing.  @trwnh this was a fascinating read, thanks for sharing. Looking forward to the blog post. I've had thoughts along those lines since I've started using Mastodon and getting familiar with AP, which I always saw as an extension of email and Usenet rather than a more general tool for the “social web” —and even for that it's being held back by the absence of a “content independent” AP server (AFAIK the only one in development is Vocata, and it still has some way to go). @oblomov yeah, there's the old "it's like email but for websites!" which isn't terribly inaccurate, but that's honestly more a consequence of "HTTP POST to ldp:inbox" than anything else in AP. the side effects for each activity kinda stray from that model and go into almost RPC-like territory. there's also some potential redundancy with HTTP verbs, but that's because HTTP verbs don't notify arbitrary audiences (although i guess they could do that with a header!) @trwnh actually what made me think of “extensions of email and newsgroups” was more the object structure, but on second thought that's more an ActivityStream characteristic than an ActivityPub one, although an actual implementation of the C2S part of AP would still fit the bill in some sense. (Yeah, the lack of usage of DELETE and PATCH surprised me initially, but the fact it would have needed to also define how to propagate them partially explains it.)  @trwnh Is something like or BBS (on the #Gemini protocol): or Station: more what you wish? @TritTriton idk but it doesn't seem like it at first glance. i'm thinking more about something that shows up in a web browser, combined with another thing that lets you author and manage web resources more easily than current tooling @TritTriton it's more like "ugh can we go back to blogs and forums and then build from there? we took a wrong turn with the rise of social media"  @trwnh thanks for writing this thread. It sparked a lot of thoughts for me. I do have one response in the form of a question. What's stopping you from just doing the thing you want? You don't really need permission. @polotek me personally? i'm not much of a coder, i'm way better at designing a system and describing how it should work, not so much actually building it. although i am in talks with some folks who seem interested, so uh... maybe check back in like 5 years? 😁 or heck, possibly even two if we're lucky! |
Gregory's Server
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/?