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

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

That is very well stated.

--

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

I think that's the point. If you retrieve it later as part of account
migration, you can check the hash as a checksum.
With regard to IPFS CIDs, I suggest using them with these multicodecs for
JCS (JSON Canonicalization Scheme) and URDNA (RDF Canonicalization input
into w3c rdch)
<https://github.com/multiformats/multicodec/pull/261#issuecomment-1260441084>
(see bengo supports the W3C RCH WG
<https://github.com/w3c/rch-wg-charter/issues/38>)
Some may also like reading FEP-8b32: Object Integrity Proofs
<https://socialhub.activitypub.rocks/t/fep-8b32-object-integrity-proofs/2725>
which could also be useful.
I think this is a big advancement.
I think we should go one step further and do the integrity proofs at the
zcap <https://w3c-ccg.github.io/zcap-spec/> level, but those methods are
not mutually exclusive and I think compose well enough.

--

I also remembered, as is easy to forget, that the specs link to
implementation reports, and that could be a useful resource for
interoperating.
https://github.com/w3c/activitystreams/tree/master/implementation-reports
https://activitypub.rocks/implementation-report/

That could be another thread entirely though.
(what if there was a fediverse implementation report protocol! 🤓)



On Sat, Mar 4, 2023 at 12: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).
>