Re: Is ActivityStreams Collection under-specified?

a wrote

> i'm not sure why you would apply CRUD to Collections. we have Add and
> Remove.:

My point is that the very generic "Add" and "Remove" Activities are defined
in the ActivityStreams Vocabulary
<https://www.w3.org/TR/activitystreams-vocabulary/#activity-types>, mixed
in with a bunch of "social" Activity types that are irrelevant to someone
who is implementing a stand-alone Collection or a Collection in some
non-social application. Also, there is essentially no discussion of what
these activities mean when applied specifically to a Collection, what
Collection-specific error handling might be needed, how access rights are
to be handled, what Collection-specific conformance test might be defined,
etc. The implementer of a Collection needs to ignore most of what is in the
Activity* specifications. Such messiness is not useful.

ActivityStreams and ActivityPub do not mandate any specific authentication
> or verification or proof mechanism. *if they had, they would very quickly
> be outdated.*

No. I don't think so. We could today adopt a profile of RFC7515
<https://www.rfc-editor.org/rfc/rfc7515>, JSON Web Signature (JWS), and be
confident that it would remain useful as long as whatever cryptographic
algorithm had been specified as preferred was still considered useful.
Then, when that algorithm becomes deprecated, as all such algorithms one
day will become, we could agree to commonly prefer some new algorithm in an
updated profile, while preserving all of the algorithm-independent code
related to signatures and all the code that relies on signatures. Yes,
there is an issue concerning the persistence of any signing algorithm's
utility, however, we can be certain that no algorithm currently known will
remain useful forever. Waiting for the development of such an algorithm is
probably a fool's errand and ensures that we'll never be able to enjoy the
benefits provided by signatures.

In any case, signatures are only useful if their readers know what they are
and trust the algorithm used. So, there really isn't much difference
between a signed object read by code that doesn't handle signatures, an
object with no signature, one signed using an unknown algorithm, one signed
using revoked keys, and one made with a deprecated algorithm. None of them
should be trusted by verifying code. Signatures you trusted one day may not
be trusted on the next day, but while they are trusted, they can be very
useful.

> If items in my collection need to refer to each other
> refer *how*, precisely? `tag` is intended as a general "inclusion by
> reference" mechanism, but there also exists the more specific `inReplyTo`
> for when your object is in some way a response to another object.

Consider an object that speaks about some other object. An example might be
a Note identifying the author of some web page. The intent is neither to
"include by reference" nor to "respond" to the web page. The intent is
merely to provide some meta-data for the web page. I could list out many
different motivations for one object including a reference to another, but,
it probably isn't either useful or even possible to come up with an
exhaustive list. This would argue for providing a simple general mechanism
for making references (i.e. Annotations) and then allowing those
References/Annotations to have types (i.e. tag, InReplyTo, about, like,
dislike, etc.)

bob wyman


On Mon, Mar 13, 2023 at 5:31 AM a <a@trwnh.com> wrote:

> > it says nothing about the interface for performing even basic CRUD
> operations on those Collections. (e.g. CRUD = Create, Read, Update, Delete)
>
> i'm not sure why you would apply CRUD to Collections. we have Add and
> Remove.
>
> > If I want to sign, or encrypt a Collection, or some or all of its
> elements, I get no guidance from any of the existing Activity*
> specifications. If I look around hard enough, I might stumble across the Verifiable
> Credential Data Integrity <https://w3c.github.io/vc-data-integrity/> and
> find in it some guidance on signing chunks of JSON-LD, but I'm not really
> sure if anyone else would be able to understand such signed JSON-LD.
>
> yes, ActivityStreams and ActivityPub do not mandate any specific
> authentication or verification or proof mechanism. if they had, they would
> very quickly be outdated. i'm sure more work is ongoing with VCDI regarding
> this general issue of verifiability and data integrity proofs, some
> discussion of which can be found with FEP-8b32:
> https://socialhub.activitypub.rocks/t/fep-8b32-object-integrity-proofs/2725
> -- the problem of course is deciding on a cryptosuite. cryptosuite churn is
> the biggest problem in general, as any proof you generate today will
> probably soon be useless on account of no one knowing how to verify it in a
> few years. see RsaSignature2017 as used in mastodon's implementation of the
> old Linked Data Signatures draft, which is not even defined anymore since
> it was formalized as RsaSignature2018, and even *that* is still a draft.
>
> > If items in my collection need to refer to each other
>
> refer *how*, precisely? `tag` is intended as a general "inclusion by
> reference" mechanism, but there also exists the more specific `inReplyTo`
> for when your object is in some way a response to another object.
>
> > how can I spend more time coding and less time digging through
> discussion lists of standards groups?
>
> i'm not sure there's a good answer to this question. if you want to
> implement a standard then you'll probably end up looking at either the
> standard itself, or at some implementation guide or tutorial.
>