Minutes from 2 May 2024 WG Meeting

Evan Prodromou

@julian @nutomic Page is not for objects with `content`. It's for links to Web pages and applications, with metadata. It shouldn't have been used for Lemmy posts.

Mike Macgirvin 🖥️

@[email protected]

"how do you feel about the use of context in the exact same way that target is used (invalidly according to as2-vocab, i might add)?"

Was just contemplating this statement, and will assert that it is possibly incorrect. The first activity in a collection operation is to Create an object in the target Collection, especially if it is a remote identity to the collection instance. This activity should be ignored by everybody except the owner (attributedTo) of the Collection, who will perform an Add (object) to Collection - or potentially ignore/reject it. This workflow is the fundamental basis of FEP-400e.

If that workflow is invalid, we'll have to discard FEP-400e and start over.

Mastodon will happily toss the target and display a Create Note (if the object is a note), and completely ignore the resultant Add/object/Collection activity. This is not my problem, and we have to co-exist with non-compliant implementations. It's not like we can stop them.

I would also suggest that the probability of project 'xyz' in the fediverse handling an array in the context without chucking an exception is less than 50%. This is also a reality we need to deal with. Maybe I'm wrong and maybe more projects have fixed their stuff since we last tried using an array on a field that Mastodon always sets to a string, but I would definitely run some interop tests and probably file lots of bugs on lots of projects before attempting it in production. And those projects will happily ignore the bug report for years if your platform has under 1 million users. That's the way the world works.

In any case the initial Create activity with a target is completely valid. But the only actor that "should" ever act on it is the Collection attributedTo. Everybody else "should" discard it, if they are compliant with the Collection workflow described in FEP-400e.

That said, I don't think we're completely compliant with FEP-400e either. I recall a couple of sticking points and we've extended it beyond its initial scope of groups. We're primarily using it as the basis for this basic Collection management workflow.

infinite love ⴳ

@mikedev Ah, I should clarify: Create with target is valid, but not immediately meaningful. Object with target is invalid because target is only defined for Activity types.

7888 uses the same Create/Add workflow as 400e but uses the “correct” property for this.

The use of multiple contexts is… possible, but it’s like using multiple inReplyTo. The main issue is where to send your activity for approval.

Mike Macgirvin 🖥️

Thanks for the clarification. I'll take a look after another cuppa.

Mike Macgirvin 🖥️

I guess the real question is - if an 'object' field (an Activity is an extension of Object) cannot contain an Activity, how would you then Add a Like/Dislike/Attend/etc. Activity to a Collection of Activity?

infinite love ⴳ

@mikedev I meant non-Activity types can’t have “target” property. Nothing to do with “object” property.

You can Add a Like (etc.) just fine.

Mike Macgirvin 🖥️

@[email protected] Then I guess I'm not seeing what you have an issue with, unless it's just a poor description of something in my container documentation. I don't think that I'm actually using a target anywhere that isn't associated with an activity.

infinite love ⴳ

@mikedev My mistake, FEP-400e does, and I was under the impression Conversation Containers did as well. https://w3id.org/fep/400e#using-target-in-objects

I had another look at https://codeberg.org/streams/streams/src/branch/release/doc/develop/en/Containers.mc and my only nitpick is that the initial Create would make more semantic sense as a dual-typed ["Create", "Add"]. With that said... I understand why you didn't do it that way.

Also I still think that context+target is redundant since they point to the same collection. But again, that's the price of compatibility.

[email protected]

The Activitystreams standard doesnt mention that. And it makes a lot of sense for Lemmy, because the comments are a major part of it.

silverpill

@mikedev Okay, I think I'm starting to see the big picture here. When a group actor publishes Add or Announce activity which wraps another activity, the recipients should somehow verify the authenticity of a wrapped activity. With FEP-8b32 this is easy. Without FEP-8b32 you need to fetch the wrapped activity from its server of origin. However, when the group is private the activity would be private as well, and everything becomes complicated. The originating server may not know who is part of the group and who is not, and therefore it can't enforce privacy by requiring a signed fetch.

To work around this in his non-FEP-8b32 implementation of FEP-400e, @grishka invented "actor tokens": https://codeberg.org/fediverse/fep/src/branch/main/fep/db0e/fep-db0e.md

Am I getting this right?

Curiously, the authentication of wrapped activities is not described in FEP-1b12. I posted about this problem on SocialHub forum yesterday but haven't gotten a response yet: https://socialhub.activitypub.rocks/t/fep-1b12-group-federation/2724/66

Is it so obvious that it doesn't need to be stated? Or is there a huge security hole in existing FEP-1b12 implementations because no one have bothered to think about this?

Mike Macgirvin 🖥️

Third party issues are subtle enough that they're obvious only after you actually have to deal with them. I've been dealing with them for a long time now. Both in private groups and multiple protocol interactions - where we were trying to make something from protocol 'A' visible to somebody using protocol 'B' when we ourselves used protocol 'C'.

Tokens are one way to do it, but they can be real tricky to secure, and they need to be stripped from conversational objects or inReplyTo's and de-duplication don't work correctly. Or give everybody in the conversation the exact same token - in which case they don't really provide very good access control. These are things most people don't come to grips with until they try it.

We've traditionally implemented private groups in other protocols by doing a straight resend/relay of a signed activity by the group actor, and we did this in AP with LD-signatures for a while. I don't think Mastodon supports relaying any more because they're now verifying sender-id (via the HTTP-sig) against actor-id and rejecting mismatches.

FEP-8b32 along with Collections conveniently gets around all of the related issues. The sender and actor id of the Add activity matches, and the object is a complete signed activity.

silverpill

@julian ^ How it works in NodeBB? Do you authenticate wrapped activities?

@grishka @mikedev

julian

@[email protected] said in Minutes from 2 May 2024 WG Meeting:

Do you authenticate wrapped activities?

Do you mean something like a Announce(Note)? If it's Announce(Create(Note)), I am pretty sure NodeBB doesn't handle that yet, so they're dropped.

But for the former... on the way in, if object is anything other than a uri, we check it's origin. If it matches the actor, then we assume validity. Otherwise we retrieve the object anew from the source.

We don't currently support integrity proofs (8b32) or actor tokens (db0e) yet, so if the object cannot be retrieved, then the entire activity is dropped as unprocessable.

julian

@[email protected] specifically for NodeBB, we don't handle non-public content yet, so we've neatly sidestepped this issue temporarily

silverpill

@julian Makes sense. Accept if origin is the same, otherwise retrieve from source. I think Announce(Create(Note)) and other FEP-1b12 activities should be processed in the same way:

FEP-1b12: Group federation

Internet forums are probably the oldest form of social media. They can be implemented with the Activitypub protocol, but such implementations may not necessarily be compatible with each other. This document defines a com…

SocialHub (socialhub.activitypub.rocks)

julian

@[email protected] is the sending of Announce(Create(Note)) an implementation quirk, or is it explicitly defined in an FEP?

My assumption is that you announce Likes and Notes, but I guess there's theoretically nothing stopping someone from Announcing that someone Liked your Announce of a Creation of a Note — a Announce(Like(Announce(Create(Note))))

... but... yikes.

silverpill

@julian Activities like Announce(Create(Note)) are the main point of FEP-1b12:

>In case the incoming activity is deemed valid, the group MUST wrap it in an Announce activity, with the original activity as object.

Announce(Note) is an additional activity that Lemmy sends to remain compatible with micro-blogging apps.

julian

@[email protected] Understood... in that case NodeBB should handle the wrapped activity. That might take some refactoring, but nothing major. Thanks for the clarification.

a

Yup! You can wrap that onion as big as you'd like. Nothing stopping you except for convention. It's like how people on Twitter will sometimes quote tweet each other in a really long chain.

julian

@[email protected] said in Minutes from 2 May 2024 WG Meeting:

Yup! You can wrap that onion as big as you'd like. Nothing stopping you except for convention.

I'm having a tough time figuring out in my head how my backend is supposed to handle receipt of an activity with n-layers. Just the thought of each layer of said onion having their own side-effects is causing my brain to stop working.

Perhaps this is a scenario where each object having an ID would be helpful?

Contrived e.g. Announce(Like(Announce(Create(Note)))) might have ids e > d > c > b > a, but if my backend has already processed a, b, and c, then I only have to consider d and e?