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

I think it's clear to everybody that the specs and the implementations that
use them are very much out of sync. However, I just don't think we have the
implementation experience necessary yet to know which parts of the specs we
should keep and which parts of the specs we should throw away.

So far, as an implementation community, we've managed to create
approximately 3 popular ActivityPub implementations—Mastodon, Pleroma, and
Misskey. These are the only implementations that  have had a wide enough
exposure to a significant non-technical user base that I would consider
them to encompass new UX learnings

But all three of those software projects predate ActivityPub to a
significant extent—Mastodon was built for OStatus, Misskey spent the first
half of it's lifespan non-federated, and Pleroma began as a GNU Social
frontend until it was given an ActivityPub backend. None of these projects
implement Server to Server federation in the way it was envisioned in the
activitypub spec—generic backends storing diverse payloads to be given
meaning by a panoply of client applications. Setting in stone today what
one needs to do to interoperate with these platforms would cut off
experimental and extensible nature of ActivityPub in favor of creating a
"dead standard" exactly like this thread seeks to avoid. Any specification
effort should instead seek to happen the other way around—work with these
projects to understand which parts of their legacy infrastructure no longer
serve them well, or crafting new, compelling user experiences that these
projects can't deliver because of their legacy architecture, and finding
user adoption that way. Once we have more implementation experience with
what works and what doesn't work only then will we have the answers
necessary to start a living spec process that can ensure interoperability.

More simply put—standards can't drive change. Only change can drive
standards, or the standards will simply be ignored.

Finally, on the other side of the coin, there are significant new
transformative ideas that aren't in any social standard anywhere, such as
decentralized identifiers and object capabilities. Some small experimental
projects have shown small things with regards to these ideas, but I don't
think we're even at a state yet where you can imagine having a social
network like mastodon built upon decentralized identifiers. So here I think
more experimentation is needed as well, but it's smaller scale
experimentation, more well-suited for a one-off tech project.

As far as object capabilities go, I think the rubber has really met the
road in terms of reply approval and the pressing need for that today as a
social interaction tool. So I encourage everybody to go check out the reply
approval FEP conversation and contribute to it, because I think it's going
to end up significantly shaping what object capabilities look like on the
fediverse.


On Sat, Mar 4, 2023, 2:05 AM a <a@trwnh.com> wrote:

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