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

>
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.

I think we most entirely agree.

Are there any particular issues you have in mind that are in the spec's
issue tracker? https://github.com/w3c/activitystreams/issues

We can improve the existing ActivityStreams standards by writing extensions
that get adopted enough to provide evidence for how or whether to improve
w3c standard and whether any given change would, in fact, be improving it.
A lot of people are working hard to do that through things like the issue
tracker, socialhub forum, FEP processes, loose consensus and running code,
etc.

I think updating the w3c activitystreams namespace is an extreme
application of privilege, and one that we should not delegate without
extreme scrutiny e.g. by a w3c wg charter or considering alternative
options like those mentioned above, and engaging with the other people that
have found ways to cocreate a fediverse without exercising that privilege
<https://en.wikipedia.org/wiki/Principle_of_least_privilege>.

But I totally agree we can improve the standards ecosystem as a whole, and
I think there is a lot of low hanging fruit we can discuss in the weeds in
the issue tracker or FEPs.

bob:
> 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"

a:
> Hopefully I've shown why the specs are fine, and it is instead the
"conformance profiles" that should be built (after a conceptual space is
identified).

I think you can make a conformance profile of a Focused Social Vocabulary
as a FEP.

> (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.)

The vocab spec says:
> By default, the value of content is HTML.

I think it would be misleading if there was no example using `content`
without `mediaType`, which I've used quite a bit.

> (e.g. Basic rules for constructing and describing objects, such as
signatures, encryption, rights or capabilities expression,
instance-independent content-based identifiers, etc.)

fep-8b32 (last email), fep-c390
<https://socialhub.activitypub.rocks/t/fep-c390-identity-proofs/2691>, are
all helpful to this.
And maybe we can have a thread on each of those things on this mailing list
as well?


On Sat, Mar 4, 2023 at 9:25 AM Bob Wyman <bob@wyman.us> wrote:

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