the first thing you need to accept in an open world is that people will say and do different things.
Uncategorized
13
Posts
1
Posters
0
Views
-
if you try to make everyone say the same things, you actually make the problem worse, because people are going to end up saying the same thing but with different meanings. you get consistent vocabulary but inconsistent meaning. this is otherwise known as ambiguity or equivocation.
this is basically what happened with activitystreams as it gets used in fedi. the terms are defined by the w3c, but softwares don't use those definitions strictly. they have local concepts and abstractions, then they try to use whichever as2 term they feel is suitable. the mistake is assuming everyone else will inverse-map the as2 term to the same local concept or abstraction.
it would be better to just be explicit and describe/define your own local concepts instead of enforcing a lingua franca
-
this is basically what happened with activitystreams as it gets used in fedi. the terms are defined by the w3c, but softwares don't use those definitions strictly. they have local concepts and abstractions, then they try to use whichever as2 term they feel is suitable. the mistake is assuming everyone else will inverse-map the as2 term to the same local concept or abstraction.
it would be better to just be explicit and describe/define your own local concepts instead of enforcing a lingua franca
example: mastodon maps its Status to as:Note and its Account to as:Person or as:Service. what if it didn't strictly need to? when federating with another mastodon-like processor, the translation is unnecessary; when federating with a processor with a divergent interpretation, it can even be incorrect. what mastodon wants to know is if the Thing is a Status, but it can only be told the Thing is a Note. this makes it impossible to have a Note that isn't a Status, or a Status that isn't a Note.
-
example: mastodon maps its Status to as:Note and its Account to as:Person or as:Service. what if it didn't strictly need to? when federating with another mastodon-like processor, the translation is unnecessary; when federating with a processor with a divergent interpretation, it can even be incorrect. what mastodon wants to know is if the Thing is a Status, but it can only be told the Thing is a Note. this makes it impossible to have a Note that isn't a Status, or a Status that isn't a Note.
if mastodon had its own defined processing model that looked for its own defined terms (or their equivalents!) then this would be less of an issue. the problem with activitystreams is that its intended processing model is a) not formally defined/described in the spec, b) fundamentally different than mastodon's processing model.
activitystreams actually made more sense as an extension to atom, because in that case you are basically saying that a Thing is both an atom:entry and an as:Activity.
-
if mastodon had its own defined processing model that looked for its own defined terms (or their equivalents!) then this would be less of an issue. the problem with activitystreams is that its intended processing model is a) not formally defined/described in the spec, b) fundamentally different than mastodon's processing model.
activitystreams actually made more sense as an extension to atom, because in that case you are basically saying that a Thing is both an atom:entry and an as:Activity.
your typical atom processor could understand the atom:feed and look at each atom:entry for its atom:content. but your activitystreams 1.0 processor could look for the activity:verb and activity:actor and so on. the two processing models can exist side by side in the same document. the same document can be read in different ways by looking for different terms. maybe some terms have the same value across different contexts, but are you expected to know that upfront, or told that explicitly?
-
your typical atom processor could understand the atom:feed and look at each atom:entry for its atom:content. but your activitystreams 1.0 processor could look for the activity:verb and activity:actor and so on. the two processing models can exist side by side in the same document. the same document can be read in different ways by looking for different terms. maybe some terms have the same value across different contexts, but are you expected to know that upfront, or told that explicitly?
imagine how bad it would be if as1 was specified to reuse atom vocabulary but with different meanings. you'd never be able to tell if an atom feed was an atom feed or an activity stream! you'd just run into unexpected values randomly.
now, to some extent, these kinds of processing models and data models and semantics are typically part of the iana media type or http content-type. application/atom+xml isn't the same as a hypothetical application/as1+xml. but documents can only have one such type
-
imagine how bad it would be if as1 was specified to reuse atom vocabulary but with different meanings. you'd never be able to tell if an atom feed was an atom feed or an activity stream! you'd just run into unexpected values randomly.
now, to some extent, these kinds of processing models and data models and semantics are typically part of the iana media type or http content-type. application/atom+xml isn't the same as a hypothetical application/as1+xml. but documents can only have one such type
in http the content type can be negotiated with the Accept header, but when you do this kind of content negotiation, you aren't just negotiating the serialization or data format. you are also negotiating a processing model! otherwise, we would just serve everything as plain old application/json or application/xml or text/plain. these "less specific" types are relatively unconstrained on what you can do with them; they make no assumptions beyond "you will parse this with a generic processor"
-
in http the content type can be negotiated with the Accept header, but when you do this kind of content negotiation, you aren't just negotiating the serialization or data format. you are also negotiating a processing model! otherwise, we would just serve everything as plain old application/json or application/xml or text/plain. these "less specific" types are relatively unconstrained on what you can do with them; they make no assumptions beyond "you will parse this with a generic processor"
more specific types will further constrain your processing model or semantics:
- application/octet-stream might open in a hex editor
- text/plain opens in a text editor
- application/json is loaded into a json processor
- application/activity+json is loaded into an activity processor, and also defines what terms like "actor" and "object" mean in the first place. you know that "actor" means "who performed an activity" and not "who performed a role in a movie". -
more specific types will further constrain your processing model or semantics:
- application/octet-stream might open in a hex editor
- text/plain opens in a text editor
- application/json is loaded into a json processor
- application/activity+json is loaded into an activity processor, and also defines what terms like "actor" and "object" mean in the first place. you know that "actor" means "who performed an activity" and not "who performed a role in a movie".now, here's the exercise left for the reader: how do you signal that you want to process a mastodon status?
as a hint, consider a similar question that can be asked about atom and as1. how do you request an activity stream in as1? in that case, the same document might be served for both negotiated types (atom and as1). is this possible for heterogeneous fedi processing models?
-
now, here's the exercise left for the reader: how do you signal that you want to process a mastodon status?
as a hint, consider a similar question that can be asked about atom and as1. how do you request an activity stream in as1? in that case, the same document might be served for both negotiated types (atom and as1). is this possible for heterogeneous fedi processing models?
well, my answer is, there are two ways to do this:
1) everyone agrees ahead of time on what words should mean and what should be done. (this is turning the open world into a closed world.)
2) everyone uses their own words but tries to understand the words of others. over time, equivalences are mapped, and models can evolve and perhaps converge or diverge as appropriate.
-
well, my answer is, there are two ways to do this:
1) everyone agrees ahead of time on what words should mean and what should be done. (this is turning the open world into a closed world.)
2) everyone uses their own words but tries to understand the words of others. over time, equivalences are mapped, and models can evolve and perhaps converge or diverge as appropriate.
i think the missing infrastructure that makes people lean more toward 1 than 2, is that we don't have minimally-agreed-upon ways to do that kind of equivalence mapping. you have to obtain that knowledge out-of-band. the iana won't tell you which types are equivalent, and http generally won't let you say that some resource can be processed in multiple ways, and filesystems rely too much on file extensions to handle this gracefully.
-
i think the missing infrastructure that makes people lean more toward 1 than 2, is that we don't have minimally-agreed-upon ways to do that kind of equivalence mapping. you have to obtain that knowledge out-of-band. the iana won't tell you which types are equivalent, and http generally won't let you say that some resource can be processed in multiple ways, and filesystems rely too much on file extensions to handle this gracefully.
right now, this kind of equivalence information is hardcoded into the codebases of each fedi software. if you want to understand it, you have to go reading each and every codebase you care to interoperate with. that is the source of truth. there might be some html or markdown documentation available, but it is not a source of truth.
and of course, these fedi softwares just assume a whole lot of things that can't be safely assumed.
what if they didn't have to assume?
/thread
-
undefined oblomov@sociale.network shared this topic on
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Nun copriamo più le scarpe ortopediche. Esticazzi?
Tanto 'ndo vanno se sò disabbili?
-
@mcc valid
-
@Linkshaender even a $15 Tamagotchi from the 90s had a better CPU than Voyager
-
@mcc Related - most of the 60s actually happened in the 70s.
-
Jesus thinking... "maybe I'll return just to fuck with crypto bros".
-
@nickthewright @mrencyclopedia He looks like he’s about to give those stinking elves what for!
-
@gsuberland well, at least it has a flared base
-
@SmudgeTheInsultCat at least twice a day, as a little treat
