Re: Reconciling theory and in practice -- do the specs need updating?

Ben Goering
<https://lists.w3.org/Archives/Public/public-swicg/2023Mar/0015.html> wrote:

> Instead of trying to specify the fediverse, I suggest that it is more
> appropriate to practice acceptance that one of the main vibes of fediverse
> is decommodification <https://en.wikipedia.org/wiki/Decommodification> (which
> aids its adaptability and resilience), and that that is in direct conflict
> with any goal to.... commodify it via specification.


I have no interest in commodifying the Fediverse. If anything, I'd like to
see greater decommodification of the user experience and greater variety in
clients and applications. I agree strongly with nightpool
<https://lists.w3.org/Archives/Public/public-swicg/2023Mar/0020.html#:~:text=generic%20backends%20storing%20diverse%20payloads%20to%20be%20given%0Ameaning%20by%20a%20panoply%20of%20client%20applications>
that
we should have *"generic backends storing diverse payloads to be given
meaning by a panoply of client applications."* But, today, I fear that
we're not doing a good job of fulfilling that vision. Spec modifications
could support making progress towards realizing the vision.

Decommodification relies on commodification. And no, that is not like
saying "War is Peace. <https://en.wikipedia.org/wiki/Nineteen_Eighty-Four>"
Either market or communication systems, if they are to support diversity of
either product or message content (i.e. decommodification), must rely on
*commodification* of the means of distribution. (e.g.  standards for roads,
rails, network protocols, etc.) Communication systems additionally rely on
common standards for expressing information. (e.g. grammar, basic
vocabulary, and vocabulary extension mechanisms)

Given the above, I suggest that if ActivityStreams is to better facilitate
decommodification and a true "panoply of client applications," it must do a
more effective job than it now does of commodifying at least the essential
elements required by those decommodified systems. In some cases, that means
adding things to the ActivityStreams Core
<https://www.w3.org/TR/activitystreams-core/> standard. (e.g. Basic rules
for constructing and describing objects, such as signatures, encryption,
rights or capabilities expression, instance-independent content-based
identifiers, etc.) In other cases, I would suggest moving things out of the
generic Activity Vocabulary
<https://www.w3.org/TR/activitystreams-vocabulary/> and into a more focused
"Social Vocabulary" (e.g. activity types such as "Like" and "Dislike" are
of little use to non-social applications. I'd also suggest a better
demonstration of expectations that support federation. (e.g. The
ActivityPub document has many examples showing "content" with no
"mediaType." This encourages folk to implement without mediaType since they
assume "all my clients will know I don't support markdown..." But, such
assumptions break federation. So, I'd like to expand the examples to
include mediatype.)

We were all well-served by the commodification of networking standards in
the 1990's -- when TCP/IP won the then two-decades old "protocol wars
<https://en.wikipedia.org/wiki/Protocol_Wars>." Once we had a common
network protocol, a vast array of higher level application protocols could
be developed without fear of vendor lock-in. Back in the 1940's, my
grandfather fought a similar battle, representing Zenith in the standards
group whose work replaced broadcaster- or manufacturer-specific television
standards (including Zenith's). Acceptance of the NTSC broadcast standard
enabled a flowering of diverse (although sometimes regrettable) video
content, at least in the US. Of course, the fact that other countries
adopted their own broadcast standards restricted international distribution
of TV content for many decades.

Working to improve the existing ActivityStreams standards would strengthen
them and encourage their broader and easier adoption. Improvements to the
standards could, I believe, encourage the decommodification that you value.

bob wyman

On Fri, Mar 3, 2023 at 6:55 PM Benjamin Goering <ben@bengo.co> wrote:

> I guess we have several choices:
>>
>> 1. Attempt to reactivate W3C Social, and go through a formal process to
>> update the spec. Formally reach out to IETF and simultaneously update
>> Webfinger. Get extra standards work started that currently has no home.
>> Pro: all nice and proper. Con: expensive in work time and calendar time and
>> there may not be resources for this.
>>
>
>  I hope this doesn't happen.
>
> 2. Declare Mastodon the market leader and whatever it implements as the
>> standard. (I’m only partially kidding; this is what will happen by default
>> if we do nothing.)
>>
>
> It seems like what you want is
> * interoperability with mastodon and 'as many Fediverse apps as possible'
> * a specification for how to do that
>
> If that's the goal, I don't think touching the as2 or ap specs will help.
> Mastodon existed before as2 or ap. The Fediverse existed before as2 or ap.
> Mastodon *never* was trying to implement only w3c specs such that others
> could implement those specs and expect to interop with mastodon.
>
>
>> 3. Something in between those two extremes. For example, we could create
>> an updated “implementor’s guide” that says “do this, don’t do that, to be
>> current in 2023” AND make sure that implementors understand that’s the
>> baseline to work from. In the meantime, for example.
>>
>> Many other choices … other ideas on need and how to address the need?
>>
>
> If you want to interop with as many Fediverse apps as possible, doing the
> n**2 work of talking with other implementors (it's only O(n) for you) and
> engaging with a Fediverse Enhancement Proposal process is the best way to
> do it I know of.
>
> I think getting updating as2/ap or writing a new spec  about what the
> fediverse under the w3c banner won't help with the goal of interoperating
> with all the existing fediverse apps that ignored the w3c in the first
> place.
>
> Instead of trying to specify the fediverse, I suggest that it is more
> appropriate to practice acceptance that one of the main vibes of fediverse
> is decommodification <https://en.wikipedia.org/wiki/Decommodification>
> (which aids its adaptability and resilience), and that that is in direct
> conflict with any goal to.... commodify it via specification.
>
>
> On Fri, Mar 3, 2023 at 2:46 PM Sean O'Brien <sean.obrien@yale.edu> wrote:
>
>> I agree with Bob and Johannes's points, in general. Standards that aren't
>> updated regularly become historical documents only.
>>
>> I am very interested in the role of confidentiality and encryption, and I
>> know some work has been done by others in the community that extends
>> ActivityPub in that direction (for ex. the use of PGP keys). I think it's
>> vital to consider folding the appropriate components of these proposals
>> into updated specs.
>>
>> Cheers,
>> - Sean
>>
>> --
>> Sean O'Brien
>> Fellow, Information Society Project at Yale Law School
>> Founder, Privacy Lab at Yale ISP, https://privacylab.yale.edu
>>
>>
>> On March 3, 2023 7:56:57 PM UTC, Bob Wyman <bob@wyman.us> wrote:
>>>
>>> You write:
>>>
>>>> There's nothing that needs to be changed about the specs
>>>
>>> I disagree. I agree with Johannes Ernst that we should at least consider
>>> whether, after five years, the Activity specs are in need of clean-up,
>>> modification, or extension. It may be that the specs did not declare
>>> themselves to be 'living standards,' but my many years experience with
>>> standards has taught me that "An unchanging standard is probably a dead or
>>> dying standard." In virtually all, but not all, cases, the original
>>> standards writers did not and could not have anticipated how experience and
>>> the evolving environment would change requirements in the future. (Note: I
>>> remember when we were working on AS1... We've all learned a great deal
>>> since then and while AS2 captured some of that learning, even more has been
>>> learned during the past five years.  It would be extraordinary if the
>>> authors of AS2 were to claim a degree of clairvoyance not experienced by
>>> the vast majority of other standard writers...)
>>>
>>> The purpose of standards is to enable interoperation between
>>> independent implementations without the need to understand the
>>> peculiarities of individual implementations. Such
>>> implementation-independent interoperation is far from what we have in the
>>> SocialWeb today. The best we can say about implementations like Mastodon is
>>> that they are "inspired by" ActivityStreams/ActivityPub. That's not enough
>>> to ensure standards-based interoperation.
>>>
>>> Johannes has pointed out a few matters that could use clarification. I
>>> agree with him that the use of WebFinger
>>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7033.html&data=05%7C01%7Csean.obrien%40yale.edu%7Ce664611ac5964c300f1808db1c2184e4%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C638134702516744374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ec5cfRD6jF3svN5Yq18taZdF67dXdQO1l4RNIeNCYHI%3D&reserved=0>and
>>> Web SIgnature needs clarification. Others have suggested that new effort
>>> should be put into the test suite or that we should develop at least a
>>> profile that describes some common agreement on how to produce signed or
>>> encrypted objects. I believe that in order to address a wide-variety of
>>> privacy and related issues concerning appropriate use of data, we should at
>>> least profile how a Rights Expression Language, such as the W3C's ODRL
>>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fodrl-model%2F&data=05%7C01%7Csean.obrien%40yale.edu%7Ce664611ac5964c300f1808db1c2184e4%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C638134702516744374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zMhXPME0mv0EE9KJcdADCkk8QzfCZ9CSM11B33MMMZ8%3D&reserved=0>,
>>> should be used to allow creators of objects to grant extended usage
>>> permissions to others. (e.g. May you index my posts in a full-text search
>>> system?) We should also consider the use of instance-independent
>>> identifiers, such IPFS's Content Identifiers (CID)
>>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.ipfs.tech%2Fconcepts%2Fcontent-addressing%2F%23what-is-a-cid&data=05%7C01%7Csean.obrien%40yale.edu%7Ce664611ac5964c300f1808db1c2184e4%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C638134702516744374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FtfRUaewbvvyTQnTxn%2BBKUes0jkn2eE%2BPVFuUoAg4fQ%3D&reserved=0> in
>>> order to allow objects to be stored and retrieved independent of any
>>> specific instance. Supporting content, not location, based identifiers
>>> would make it easier to determine when duplicate objects are received from
>>> multiple remote servers and it would help in account migration since old
>>> posts would no longer be bound to one's old instance.
>>>
>>> In some cases, the current spec seems to provide unnecessary variety
>>> with little benefit -- which may explain why only "Note" and "Question"
>>> seem to be implemented, but not many of the other object types are
>>> implemented except by specialist systems.  Can someone explain why
>>> "Article," "Document," and "Note" are all first-class objects instead of
>>> Article and Note being subtypes of Document? And, if my
>>> personally-developed client is talking to a server, like Mastodon, that
>>> doesn't support anything but Note objects, is there some way that my client
>>> can discover that the server either won't accept, or will rewrite, anything
>>> other than a Note object or Question activity? Also, AS2 defines several
>>> meta-statements, such as "Like" and "Dislike" as first-class objects. It
>>> seems to me that the spec would be simplified if it explicitly supported W3C
>>> Annotations
>>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fannotation-model%2F&data=05%7C01%7Csean.obrien%40yale.edu%7Ce664611ac5964c300f1808db1c2184e4%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C638134702516744374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=05w8Fg4UcINGWSuGzqszcGaWYQFTfAlJ7xMotlsq3KE%3D&reserved=0>,
>>> or a profile of that standard, and then said that Like, Dislike, and
>>> other statements "about" an object should be provided as Annotations.
>>>
>>> I could go on... But, I think it is clear that the current
>>> specifications don't allow one to safely develop without knowledge of the
>>> details of other specific implementations. To me, this indicates that more
>>> work on the specs is required.
>>>
>>> I believe we should build a prioritized list of issues with the current
>>> specification and begin the process of working through the development of
>>> community-supported consensus solutions.
>>>
>>> bob wyman
>>>
>>>