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

> we should at least consider whether, after five years, the Activity specs
are in need of clean-up, modification, or extension

Yes, but we should also consider *why* any of these cleanups,
modifications, or extensions are "need"ed, and for what purpose and what
use-case.

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

Would we then say that these implementations are "inspired by" HTTP, and
not actually following the HTTP standard? It's certainly true that Mastodon
et al aren't implementing ActivityPub fully (as a generic Server that
delivers activities generated by Clients), but they're still complying
(more or less) with the spec requirements. They just add extra requirements
on top. These requirements may or may not be shared between any two given
projects, because the two projects are not necessarily operating in the
same conceptual space. So, any "interoperability" needs to establish some
kind of conceptual space first, or else there is really nothing to discuss
here.

We may consider the conceptual space occupied by Mastodon to be
"Twitter-like social media platforms", but there's more to ActivityPub than
Twitter clones. We might refer to "the Mastodon conformance profile" --
that actors must have a "username" and that this actor represents a "user"
or "profile", that you must sign your messages with the old
draft-cavage-http-signatures-08, that you must include a tag of type
Mention even if you don't actually mention anyone in the content, and so
on. We might similarly refer to any other software's "conformance profile"
as the set of requirements and expectations that must be maintained for
interoperating with that software. The task, or challenge, is to then try
and find commonalities and overlaps between these conformance profiles and
see how many (or how few) distinct conceptual spaces you can collapse into.
Hint: it's not going to be just one.

> the use of WebFinger <https://www.rfc-editor.org/rfc/rfc7033.html>and Web
SIgnature needs clarification

- https://docs.joinmastodon.org/spec/webfinger
- https://docs.joinmastodon.org/spec/security

This is assuming you care about the "Mastodon conformance profile", of
course. An equally valid option would be to *not* require usernames, and
*not* use an outdated draft of HTTP Signatures.

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

This is something you can add to a "conformance profile" if you wish, or
you may just use it as-is with the existing extension workflow. It is not
something you can enforce universally, and certainly not outside of any
conformance profile.

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

Under which authority and namespace? IPFS is hash-based and will change if
the document is updated.

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

"Little benefit" here is only in the purview of the "Mastodon conformance
profile". Mastodon only cares about Notes because it is copying Twitter.
No, there's no way of knowing what the other server supports except by some
form of capability negotiation. You could probably define "conformance
profiles" and declare them somehow in your host-meta or nodeinfo.

As for the Article / Document / Note stuff, the reason Article and Note
aren't subtypes of Document is because they are "native" (just text
containers), whereas a Document is something "external" (representing a
file). As for the distinction between an "Article" and a "Note"... that
debate has been going on for far longer.

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

The concept of a "like" is inherited from social media platforms, where it
represents more than just a statement about the object. It gets added to a
collection and counter somewhere to be shown as social proof or used for
other calculations.

> To me, this indicates that more work on the specs is required.

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