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

👀
[image: Screenshot 2023-03-04 at 11.07.00 AM.png]
https://trustbloc.github.io/did-method-orb/



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

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