bengo
⚠️ We’re now entering the “extinguish” part of “Embrace, extend, extinguish”. We’ve had the first proposals in @socialcg to remove requirements of #activitypub that have been in place for 7+ years, and without an explanation how the removal improves anything.
https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extinguish
React if you’d like a #ActivityPubSpecAlert when there are proposals to change the requirements of ActivityPub as we’ve begun to see the last couple weeks.
silverpill
@raucao I don't know what @bengo is talking about, but yes, some of the proposed changes are outright harmful. For example, there is an attempt to label https://www.w3.org/ns/activitystreams#Public special URI as invalid.
Râu Cao ⚡
@bengo @socialcg Posting vague accusations without any concrete information and sources is very bad form. Linking to the actual information is literally what the Web was made for.
silverpill
https://github.com/w3c/activitypub/issues/404
It's quite long, but the summary is:
- AP says that the identifier of the special public collection is https://www.w3.org/ns/activitystreams#Public (section 5.6).
- JSON-LD programs may replace https://www.w3.org/ns/activitystreams#Public with as:Public. There is a note in AP that warns about this quirk.
- One proposed erratum re-frames the current normative text. as:Public is presented as a "correct" variant, and https://www.w3.org/ns/activitystreams#Public is said to be "erroneous". Another proposed erratum replaces https://www.w3.org/ns/activitystreams#Public with as:Public in all examples.
Why is it harmful?
- https://www.w3.org/ns/activitystreams#Public is used everywhere. Even among those few implementations that do JSON-LD processing, most don't produce as:Public. The whole problem is made-up.
- as:Public and Public are not valid HTTP URIs, so you need to special-case them when you parse audiences. These variants should be banned, but what happens is the opposite.
- Specification will become even more confusing than it is now, because examples will contradict the normative text.
Râu Cao ⚡
@silverpill @bengo "To maximize interoperability, consumers can accept all three representations."
Same as with the original post, it would be useful to link to actual proposals in the form of an email, or repo comment or pull request. I see only a single contributor for that wiki page, so I still have no idea who proposed what and why it's harmful. But I'd really like to know.
silverpill
There are other similar proposals, although they are less problematic. "Solutions" to non-problems are being proposed and JSON-LD is pushed aggressively despite being hugely unpopular among developers.
The whole thing needs to be forked.
silverpill
I don't know what @bengo means by EEE, but he also said
remove requirements of activitypub that have been in place for 7+ years, and without an explanation how the removal improves anything
And I gave you an example.
The OP even outlines 3 different options from his POV to start the discussion on it.
To understand what is wrong here you just need to compare those options with the actual text:
Râu Cao ⚡
@silverpill @bengo I see spec contributors having a disagreement over compatibility/priority between AP and other specs, but where's the EEE? The OP even outlines 3 different options from his POV to start the discussion on it.
The person who inexplicably blocked me right after I asked for details made vague accusations about EEE going on, and I'm still just trying to find out what they were talking about. :/
silverpill
"the identifier is foo" does not mean "the identifier MUST always be expressed using the literal sequence of characters f, o, o".
It does literally mean that. Furthermore, ActivityPub requires identifiers to be dereferenceable URIs, so even in an alternative reality where "X is Y" has a different meaning, as:Public is not a valid identifier.
ActivityStreams requirements don't matter because we're implementing ActivityPub, not ActivityStreams.
infinite love ⴳ
@silverpill @raucao no requirements are being changed here. "the identifier is foo" does not mean "the identifier MUST always be expressed using the literal sequence of characters f, o, o".
speaking of requirements, please read the first sentence of https://www.w3.org/TR/activitystreams-core/#jsonld and note the MUST.
"as:Public should be banned" is completely uncalled for.
and you currently need to special-case the full URI too! this is because it is not a real object. the real mistake is addressing Public at all.
silverpill
@steve @trwnh @raucao I was talking about the specific requirement in ActivityPub.
ActivityStreams may matter in other cases (however, as we have seen, it is not entirely clear whether "X is Y" and "X uses Y" are normative statements).
Steve Bate
@silverpill @trwnh @raucao I don't think this is accurate or helpful. The first sentence of the AP spec: "The ActivityPub protocol is a decentralized social networking protocol based upon the ActivityStreams 2.0 data format.". Later, "ActivityPub uses ActivityStreams for its vocabulary." AS2 is referenced many times in the spec. It definitely *does* matter in an ActivityPub context.
infinite love ⴳ
@silverpill @steve @raucao The only thing I can really suggest is dropping the use of the prefix mechanism by undefining the `as` term, then rewriting all other term definitions to not use the `as:` prefix. This might make sense since the media type nominally guarantees the meaning of certain terms, and you really shouldn't define your own custom terms in the `as:` namespace, so maybe it's okay to say that no one should ever use `as:`. Is that the resolution you'd prefer?
silverpill
@trwnh @steve @raucao I am not convinced that there is a problem in the first place.
ActivityPub says the identifier is https://www.w3.org/ns/activitystreams#Public. JSON publishers use full URI. Server implementations that perform JSON-LD processing (e.g. Iceshrimp) also produce full URI, they figured it out. Then, why make a change?
If this issue is purely theoretical, then it must be addressed without changing ActivityPub.
infinite love ⴳ
@silverpill @steve @raucao <Note> is <as:Note> is <https://www.w3.org/ns/activitystreams#Note>, but only "Note" is consistent with compacted JSON-LD.
Fundamentally, identifiers are expressed in different ways depending on context. The prefix mechanism produces compact URIs, which are still intrinsically URIs despite their lexical form not being a valid URI. If you care about referents, you need to expand them.
"as:Public" is canonical for object properties (type:id). Disliking this fact doesn't make it untrue.
infinite love ⴳ
Iceshrimp has hacky workarounds for interop reasons with plain JSON consumers who fail to understand the currently canonical fully conformant normal form of "as:Public" and only understand the non-canonical full URI. Hacky workarounds shouldn't be the norm. If one were to build an AS2 validator right now, the validator would produce documents that cause interop issues. That's the problem we're trying to solve. Issues like this prevent validation from being feasible.
Steve Bate
@silverpill @trwnh @raucao These kinds of discussions fascinate me. "Yeah, it's not right, but what's the problem?" 😉 It reminds me of ...
silverpill
@trwnh @steve @raucao If this issue causes an imaginary software to produce invalid documents, then it is not a real issue.
Regarding hacky workarounds: no one is forced to use JSON-LD. The need for a workaround actually suggests that there is a bug in JSON-LD processors, which for some reason mess with property values when they are URIs. That doesn't make any sense.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.