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

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://www.rfc-editor.org/rfc/rfc7033.html>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://www.w3.org/TR/odrl-model/>, 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://docs.ipfs.tech/concepts/content-addressing/#what-is-a-cid> 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://www.w3.org/TR/annotation-model/>, 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