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
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
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/?
You're viewing part of a thread.
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/?
@trwnh@mastodon.social Hmmm. In the open web we have a thing called a browser vendor whose job is de facto to act as the choke point where they are the ones who have to be aware of every implementation. Then as devs we get to black box it as "this is what web browsers support".
@darius@friend.camp 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.
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":
- is aware of the existence of
- is familiar with
- 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
labelandcomment, 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/?
<gestures to the sign>
https://social.coop/@MichaelTBacon/110634358031380559
Non-corporate/non-VC social media really needs to stop hating on "walled gardens" and start thinking about how you mind the gate that lets you into the garden and who gets in and who gets out.
If this exclusion still seems bad, start with "fascists" and then work outward from there.
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"
@trwnh@mastodon.social Ah, yes, I did miss that distinction, and it's been long enough since I did formal logic that it didn't ring a bell. I agree with your point too but yes, I see what you're doing is different.
@MichaelTBacon@social.coop 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.
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@social.coop 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@social.coop 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?
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!