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

sorry, wrong link to fep-c390
<https://socialhub.activitypub.rocks/t/fep-c390-identity-proofs/2726>
and the way it helps with encryption is that you can resolve a did to
an encryption
key agreement metthod <https://www.w3.org/TR/did-core/#key-agreement>.
soatak has also done some thoughtful writing and architecting in "Towards
End-to-End Encryption for Direct Messages in the Fediverse"
<https://soatok.blog/2022/11/22/towards-end-to-end-encryption-for-direct-messages-in-the-fediverse/>
and started an open source threat model and composition of specs on github
<https://github.com/soatok/mastodon-e2ee-specification>.


On Sat, Mar 4, 2023 at 10:52 AM Benjamin Goering <ben@bengo.co> wrote:

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