Minutes from 2 May 2024 WG Meeting

Mike Macgirvin 🖥️

I don't have any serious reservations. Nobody else is doing anything remotely similar to conversation containers and this provided a solid way to identify them outside other uses for collections in a context (of which there are many; groups/fep-400e, photo albums, lists/circles, event calendars, etc.). The missing piece is something like "this context is being used for purpose 'xyz'". That's not an insolvable problem, but I was trying to do so without adding any new vocabulary terms or tags/attachments of some kind.

infinite love ⴳ

@julian @mikedev As you probably already know, I think the better path forward is to use the actual intended property for this, which is context, and to send out Add to Collection instead of sending Announce. The "incompatibility" is simply in payload, but the consequence is significant if you want to support private forums.

infinite love ⴳ

@mikedev Hmm. I think that the "correct" way is to add new vocabulary terms and multitype the collections, so for example [OrderedCollection, Conversation]. But point taken, there is definitely a lack of signaling what exactly a collection is, what does it include, etc.

At least for the forum use-case I was thinking of two new types, a Topic (Collection of post objects), and a Forum (Collection of Topic). names subject to change of course. the pattern is broadly generic but the terminology isnt

Gregory

@silverpill @julian obviously my FEP is superior

The problem with FEP-1b12 is that it just formalizes the fundamentally flawed Announce flow. It's flawed because you have to post to what's essentially *your own personal timeline* to later have the post boosted by the group actor. Because of that, your followers can see the group post, as it technically exists outside of the group.

FEP-400e does not have this shortcoming because you create your posts "into" the group to begin with.

Gregory

@mikedev @silverpill actually, Smithereen has private (invite-only) and closed (manual approval + invites) groups, and I do have an authentication/permission mechanism to go on top of FEP-400e, what I called "actor tokens". I have it documented here: https://github.com/grishka/Smithereen/blob/master/FEDERATION.md#access-control-in-non-public-groups

Never made it a FEP because I thought that the whole FEP process was dead. Should I make one?

[email protected]

It sounds the whole discussion about Note vs Page is really asking how to get Mastodon to display your content better. But I think thats entirely the wrong question to ask. When someone complains to me that Lemmy posts look wrong in Mastodon, I simply point him to the Mastodon issue tracker. Its absolutely none of my concern how other projects render our content. There are dozens of Fediverse projects and I dont have time to go around and change things to satisfy every single one. If Mastodon developers dont want to improve things its their loss. Its important not to get blinded by Mastodons large user numbers. It really is by far the largest Fediverse platform so far, but does that really matter? If you look at centralized social media, there are actually billions of users. So a few years of growth and migration waves could catapult any well-designed project ahead of Mastodon in terms of user numbers. Its much more important to optimize for all these potential future users, rather than appease a minority on Mastodon who sticks to such a badly behaved platform. Also what does Evan mean by saying that Page shouldnt be used? Lemmy uses it since day one without any problems, its a perfectly fine type.

silverpill

@grishka Looks interesting, I think writing a FEP is a good idea. The process is not dead yet

I want to implement private groups too but it is not clear which approach is better. We discussed private groups with @nutomic and he said that FEP-1b12 can also support private groups. There is an RFC, but AFAIK it has not been implemented yet.

And here's the documentation for @mikedev 's Conversation Containers: https://fediversity.site/help/develop/en/Containers

@julian

Gregory

@silverpill @nutomic @mikedev @julian

well, the benefit of my implementation of private groups is that it already exists

I'll write a FEP about my actor tokens.

Mike Macgirvin 🖥️

The container approach works great for private communities because we aren't performing any third party fetches. The relationship is with the group actor, who relays the signed activities within an Add to Collection activity and these can be fetched directly from the group instance by anybody having a relationship with the group actor.

We're using FEP-8b32 (object integrity proofs) for signing these activities because LD-signatures have a number of issues, the most important of which is they have known limitations when nested. So in this case the third party is never fetching the activity from its origin. They have a signed activity delivered to them as the object of the Add activity.

The biggest issue by far with private group posts is the privacy of the original post in the thread. I've been in some heated debates about this. I don't expect anything different now. We revived an old fediverse concept (the bang tag) for privately addressing groups, whether the group is public or private. We also provide post-by-DM for sites that don't support bang tags. Using a bang tag (or DM) to perform an FEP-400e remote post-to-collection has the least user friction. We'll also accept simple @-mentions for public groups for compatibility with the FEP-1b12 mob, but this cannot be used with private groups for hopefully obvious reasons.

In any case, bang tags solve a lot of problems and provides some consistency between public and private groups and folks catch on to them real quick. Especially folks with historical ties to the StatusNet universe.

julian

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

Also what does Evan mean by saying that Page shouldnt be used? Lemmy uses it since day one without any problems, its a perfectly fine type.

That might've been a simplification on my part. The distinction was between Article, Note, and Page and being displayed in-app with rich HTML support.

Page, as per spec, is better handled how Mastodon already handles it: a short summary with a link to the original page.

Correct me if I'm wrong @[email protected] ?

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?