My main concern here would be that this approach seems to be going in a different direction than the other discussions. (see Standardizing on ActivityPub Groups )
I don’t want to end up with two separate ways to implement a group going forward.
I dont remember all details from that thread, but the main conclusion seems to be using FEP-400e, right? My problem with that is that there isnt yet any implementation which supports it in production (afaik), whereas the approach in this FEP is already used by multiple projects.
The “Announcing activities” thing still seems like a weird Lemmy-ism, though I also never got a clear answer on how activity forwarding is meant to work in general so I suppose this is technically valid
Doent lotide and other projects use the same approach? Is there any alternative you would suggest?
- “Implementations SHOULD ensure that activities wrapped in this way keep all their original data.”
I don’t see how this is meaningful, given that the remote server already can’t trust data being forwarded unless you use LDSigs, which to my understanding already require all the fields
The way it works in Lemmy now is that the activity gets deserialized first, and then deserialized for announce. During the deserialize step, fields which Lemmy doesnt know about are dropped. This is what I want to avoid, but maybe its not so important. Do you have any link about LD signatures for activities? Might be worth mentioning this as well.
Edit: FEP-8b21 describes a similar concept, I will include a link to that.
- Don’t love the “moderation activity blacklist”, seems like there ought to be a better option to validate these. Broadcasting follows also might make sense for some implementations, I would leave that up to the to/cc fields in the activity itself
- As always,
Deletebelongs to the content author. Something else should be used for group rejection
Okay Im rewriting this section so that moderation is optional, and can be entirely ignored by implementations. Im also removing mention of Delete as moderation activity, and leaving it to each implementation what it considers as moderation activity. Validation will be done by checking the actor against the group’s attributedTo instead.