Back

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/?

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/?

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/?

when i say "john knows sally", there are several ambiguities. we can solve ambiguities by disambiguating. one way to disambiguate is to be explicit about what any term or symbol means. one way to be explicit is to use uniform identifiers.

in particular, http/https uris have some convenient properties

- they have authority, so you can qualify an id based on who's assigning it.
- you can use the authority component as a namespace
- you can fetch the uri and it might return something useful

14/?

so let's say john is example.com/john and sally is example.com/sally

what do we use for "knows"?

well, there are multiple senses of the word "knows":

1) is aware of the existence of
2) is familiar with
3) is having sexual intercourse with

we mean definition 1. so we might use example.com/vocab/knows/1

now we have the statement:

<example.com/john> <example.com/vocab/knows/1> <example.com/sally>

this is unambiguous, but we can go one step further: we can provide definitions at the uri

15/?

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/?

so at minimum we have the following schema for knows/1

- how to represent it in plain text: "knows"
- how to define it: "is aware of the existence of"

the RDF Schema gives us `label` and `comment`, as defined by the RDF Schema.

- :label "knows"
- :comment "is aware of the existence of"

but we need to know what "label" and "comment" mean as well! not to worry, we qualify those terms with the rdfs namespace:

- rdfs:label "knows"
- rdfs:comment "is aware of the existence of"

17/?

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/?

but it's not like AS2 didn't think of this. they wrote in this requirement: https://www.w3.org/TR/activitystreams-core/#extensibility

> Activity Streams 2.0 implementations that wish to fully support extensions MUST support Compact URI expansion as defined by the JSON-LD specification.

note, you aren't required to implement all of json-ld. you just need to handle the bit where you can identify the equivalence between a uri and some arbitrary string.

but #fediverse mostly decided this is too hard, and ignore context.

21/?

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/?

so what do you actually lose out on when you ignore json-ld context?

you first have to fall back to the "implicit context", where AS2 terms are generally agreed upon, but nothing else is guaranteed.

take something like `discoverable` from mastodon. what does it mean? well, it means whatever is defined in the mastodon codebase and documentation. so we could represent that as http://joinmastodon.org/ns#discoverable or shorten that with a prefix. but if we do, then most #fediverse will choke on that.

24/?

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/?

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

@darius yeah, this is complicated by every fedi thing being its own web browser :( and this is on top of it also being its own mail server... it just ends up doing both poorly.

@trwnh

I want fedi folks to start thinking about commons instead of getting hung up on stuff that's basically warmed over "the cathedral and the bazaar."

All functional commons involve inclusion and exclusion. They are neither purely closed nor open. They are variously open or closed depending on the combination of who you are and what you want to do.

@MichaelTBacon i think you're using closed/open in a different way from how i'm using it, which for formal logic means either "everything is true unless it's false" or "there are some things i don't know, and they aren't necessarily false, i just don't know"

https://en.wikipedia.org/wiki/Closed-world_assumption

@MichaelTBacon In other words, a "protocol" needs to know everything there is to know, and it is undesirable to have unknowns. Contrast with the viewpoint that it's perfectly fine to have unknowns, and in fact, you can expect unknowns by default. You'll never have a complete view of the universe.

@trwnh

In that regard, I have to say that I think I'm still in a little bit of a grey area. The power of AP is in the fact that it can socialize a wide range of things, and I don't think that world should be closed in advanced.

At the same time, a protocol needs a set of sub-standards at least (lots of old IETF protocols had CAPABILITY commands) that let you figure out which specific closed world you're operating in.

@MichaelTBacon i'm rotating in my head the idea of a FEP that defines a conformance profile for a "social networking profile" that basically formalizes what you'd need to implement a "fediverse network", basically as a superset of AS2+AP (because AP is not enough on its own, it says nothing about message shapes or how to interpret specific props in a social network setting)

@MichaelTBacon actually my main reservations about it are like

- how much do i base it off of current practices, and how much do i base it off of *correct* practices?
- is it worth the effort? is any project going to be on board with it?
- no really, is it worth the effort? should i be putting that effort into doing the better thing from the start?

@trwnh

If I can give unsolicited advice on nebulous question . . . ;)

- If it's going to get to correct practices, there has to be a bridge to get there from current practices. Nothing will make a big jump without a transition process.
- It's not worth the effort if you do it alone, because no one else will be invested in it.

Those may be totally useless or non-sequitur to your actual concerns. Wouldn't be the first time in this thread alone I misunderstood!

@MichaelTBacon right, i'm just wondering how to nudge implementers in the "right" direction on here (story of my life for the past 5 years lol)

@MichaelTBacon unfortunately the common response to "can we make things better" is "we need $200k"

@trwnh

On a vaguely related note, I think a really interesting way to do a proof of concept of this would be to demonstrate its use in a social media game.

The old adage that everything on the internet truly only takes off at first as either games or porn is still somewhat relevant. I think a mastodon-adjacent but very much not mastodon-specific form of social gaming could be really fun, demonstrate some ideas, and bring a different set of people to the fedi.

@MichaelTBacon this has the potential to be like when people kept getting farmville activities in their facebook feeds

@trwnh I mean hopefully we're better than that! I don't think the sum total of social gaming should be people posting their wordle scores.

There was a time when a big part of the appeal of Facebook was Words with Friends and other doofy little games that lived in the platform. FB decided it could print money other ways but those were strong early draws to the platform.

A fedi version of chess or go or mancala that used AP for its moves and allowed others to follow along would be cool.

@damon @MichaelTBacon i keep thinking people just want compat with mastodon :( haven’t really seen a swelling desire to do anything different. if it’s incompatible with “mastodon protocol” people will see it as DOA unless they can get their friends on it in critical numbers. what’s the point? if we’re doing something breaking, why not go all the way?

@trwnh That’s because most people don’t know how to distinguish between AP and Mastodon. Funny you called it that as that’s exactly what I call it the Mastodon protocol. I think you can show the true potential of AP and make it enticing for those that don’t want to just build another Twitter alternative