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

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