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

Whereas my last message was discouraging attempts to specify broad
'fediverse' interop (of existing things that use json+http) under w3c,
I share Bob and others' interests in identifying use cases underserved by
the existing Social Web Protocols, and trying to design protocols that
could help.

One of the reasons I don't think it's a good idea to touch ActivityPub is
that: ActivityPub is tightly coupled to HTTP. IMHO a lot of the interesting
directions would involve decoupling from HTTP.
But this would so wildly change 'ActivityPub' that it should just be a
different thing.

One of the reasons I don't think it's a good idea to touch AS2 is that it's
a JSON-based syntax. I think it would be good to standardize
more/less/different ontologies, but I don't think the right way of doing it
is in a JSON-based syntax. I think the right way of doing it is more like
how ODRL-vocab <https://www.w3.org/TR/odrl-vocab/> did it, defining the
vocabulary away from the limited expressivity of JSON.

I'd love to use `DID` URIs all over the place in as2-compatible messages
(e.g. to use proofPurpose=capabilityInvocation for p2p-friendly authz
<https://hackmd.io/Wzbf7p4TQ5yBNOb6VNABsw#with-authorization-via-zcap-ld>).
But I don't think it's important to specify that 'activitypub' clients
should have to know how to resolve all the kinds of DIDs. It can be a new
protocol other than ActivityPub that happens to still use some AS2
semantics.

I applaud the approach of chatternet
<https://github.com/chatternet/chatternet-client-http>. Innovate as a new
thing with a new name in a specific context. If you succeed, it can serve
as a proof of concept that could be an input into a w3c charter (as was
as1). I think that is more appropriate than going straight to trying to
update the existing socialwg TRs to do things that weren't in the socialwg
charter, and can just as easily be worked on away from those documents.

On Fri, Mar 3, 2023 at 3: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
>>>
>>>