Minutes from 2 May 2024 WG Meeting
(social.coop)
from julian@community.nodebb.org to swicg-threadiverse-wg@community.nodebb.org on 02 May 2024 19:57
https://community.nodebb.org/post/99493
from julian@community.nodebb.org to swicg-threadiverse-wg@community.nodebb.org on 02 May 2024 19:57
https://community.nodebb.org/post/99493
Please see below for minutes from today's Forum and Threaded Discussions Task Force monthly meeting.
Apologies in advance if I misrepresented anybody or missed any crucial bits of information
Participants
in order of appearance
- Dmitri, @dmitri@social.coop
- Angus, @angus@socialhub.activitypub.rocks
- Julian, @julian@community.nodebb.org
- Rimu, @rimu@mastodon.nzoss.nz
- Evan, @evan@cosocial.ca
- Mattias, @pfefferle@mastodon.social
- Emelia: @thisismissem@hachyderm.io
- a: @trwnh@mastodon.social
- Dmitri invited participants to the regular SWICG call tomorrow; best place to be informed of upcoming events: SocialCG calendar — "please come by, it is free for everyone to join or listen in"
- Angus provided an update to the working group's inclusion under the banner of the Social Web Incubator Community Group (SWICG), revised name would be the Forums and Threaded Discussions Task Force, or "ForumWG" for short.
- Julian provided an update on this past month's usage of the fediverse to hold asynchronous discussion, a number of threads have been started on the respective forum categories (both of which federate out) for the working group pertaining to discussions re: agenda items, and have been fairly well received.
- Angus and Julian will update the respective handles of their categories to reflect the new working group name
"Lay of the Land" survey reports
- Angus: The general spirit of these surveys is 'these are the existing X approaches, the plurality may indicate the need to converge'
- Nomenclature
- Rimu: Document continues to be expanded upon
- Evan re-iterates that it is unlikely any implementors will change their nomenclature to match
- Angus asks whether participants find utility in the list
- Evan indicates that whatever is decided upon is best used "on-the-wire", Julian agrees and notes that the agreed-upon terminology would be used in the "Definitions" portion of any report written by ForumWG; suggests the list may be best kept as a living reference
- Rimu indicates that as the list grows, alternative ways to represent the data may be required
- Round of applause for Rimu for taking the initiative to start (and now maintain) the list
- Object Type (Article vs. Note vs. Page)
- Impetus for topic: WordPress sending out
as:Notewhenas:Articlewould be more suitable- @jupiter_rowland@hub.netzgemeinde.eu (in topic, paraphrased): Mastodon values microblogging UX and locked down their allowed html to satisfy this constraint, despite Hubzilla's pleas
- @mikedev@fediversity.site (in topic, paraphrased): Raised issue in 2017 to address issues with inline images being removed. Suggested a compromise: treat Article and Note differently (Note, text only with attachments; Article, full HTML) — Eugen 7 months later closed issue with change to further hamper treatment of Article, by showing only title and link back to source.
- @pfefferle@mastodon.social (in topic): "You can choose 'Note' if you want to have the best compatibility"
- Evan: Whether a note or article is federated, it shouldn't hamper implementation; but
as:Pageshould not be used - Mattias: Choice is given to user as to how WP maps the native Post object to ActivityPub. Historically sent out
Articlebut received a lot of pushback from early adopters. Difficult to reconcile UX with technical limitations - Evan: "An
as:Noteis a Tweet (we just couldn't call it that), anas:Articleis a blog post" - Emelia: "Should software publish different objects based on content length, even if using the same mechanism?"
- a: Big picture view — it doesn't seem complicated, but it is, because the line between them is completely arbitrary.
- Mattias: We try to autodetect (no headers, content length, etc.), would prefer different content types based on what users write, but the advantage is being able to read content natively on the user's platform of choice
- Dmitri: "I think we've got several questions in parallel:
- What SHOULD these things (Note & Article) be used for.
- What to do about Mastodon who only seems to consume Notes."
- Emelia: Don't Articles usually have titles?
- Everyone else: crickets (made us think!)
- a: https://wiki.trwnh.com/tech/spec/activitypub/confusion/note-vs-article/ (also indicates using title to discriminate Article vs. Post isn't 100%)
- a: The reason we're talking about this is because of various differring implementations - for example, in one implementor's mental model, you have a thread with a title and that is separate from the posts contained within; posts that may also have titles of their own. How do we reconcile this?
- Julian and Rimu note that @renchap@oisaur.com replied in-topic: "... we would like to improve how non-Note objects are processed/displayed in Mastodon."
- Julian mentions a compromise put forth by @mikedev@fediversity.site where Notes are smaller pieces of content with limited markup and attachments, and Articles are (sometimes) larger pieces with formatting, inline images. Additional survey/spreadsheet to be created, but we could as a group (Mastodon included) converge on a path forward and a report to the SocialCG could be authored. To be continued next month.
- Impetus for topic: WordPress sending out
- Group Actor characteristics
- 1b12 - announcing the activities of their actors, this is what Discourse and NodeBB do, other implementations have taken this approach
- @nutomic@lemmy.ml (paraphrased): "intent of 1b12 is to describe the existing status quo"
- 400e - Pubicly appendable collections; Picked up by a few other folks, also potentially Mastodon (with their new groups implementation)
- How do we treat group actors in forum/threaded implementations?
- a: 400e - Groups send Add activities, 1b12 - Groups send Announce activities, otherwise, a Group could even send regular Creates (editor's note: this is a dramatic simplication of the actual post here)
- Evan: announce style makes the most sense, understanding that folks use both - suggestion: document both but let consumers know they'll see one or both
- Rimu: Implementors can make opinionated decisions on how it should work, and adjust based on the reality of how the major players adopt
- Angus will continue collating responses into a spreadsheet re: group implementations
- Open item: feedback on desired UX (@trwnh@mastodon.social)
- Can a group be multiple different things? e.g. a context/thread has some recipients, a context could be an actor. How forums choose to (or could) represent these relationships via ActivityPub is what is currently being solicited
- a: Boils down to "Collections, please use them", but best to start foundationally: Notes in Collections, first.
- Due to lack of time discussion of this will take place asynchronously on the fediverse: https://community.nodebb.org/post/99491 (if this does not open in your client, paste it into the search box)
- Julian provided one user story: "If you want to share a context to others, one should share the higher-ordered collection, and not what we do today, which is to share the url/object uri for OP."
- A suitable implementation could see that and backfill the entire context locally, and redirect the user to the first object.
- Angus noted that Discourse already has some support for Collections, will provide details async on forum topic (linked above)
Action Items
- @angus@socialhub.activitypub.rocks and @julian@community.nodebb.org will update the respective handles of their categories to reflect the new working group name
- @julian@community.nodebb.org to collate responses to Article vs. Name among implementors, supply recommendation at next meeting.
- @angus@socialhub.activitypub.rocks to collate responses re: Group federation among implementors, continue discussion next meeting
- @trwnh@mastodon.social to solicit feedback asynchronously via the fediverse
threaded - newest
@julian @dmitri @angus @rimu @evan @pfefferle @thisismissem @trwnh @jupiter_rowland @mikedev @renchap @nutomic I keep missing these! The first one I had something come up that conflicted with it, but this one I must have just forgotten to put on my calendar. Maybe I'll catch the next one.
@arnelson@fosstodon.org Let me add you to the list-of-people-to-mention whenever something is scheduled <img alt="🙂" src="https://community.nodebb.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f642.png?v=ldhb99mgg9c">
@julian @arnelson We should also probably put it on the SocialCG calendar. @dmitri ?
@evan@cosocial.ca slightly ahead of you there <img alt="😁" src="https://community.nodebb.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f601.png?v=ldhb99mgg9c"> https://community.nodebb.org/topic/18010/adding-forum-task-force-calls-to-the-calendar
@julian
@grishka What are your thoughts on FEP-400e vs FEP-1b12 question? Is there a good reason to pick one over another?
Our conversation container work is based on and very closely related to fep-400e; and the biggest difference in my view is that it provides a mechanism for supporting protected/restricted audiences. Under fep-1b12 you're very much restricted to everything being public, as third parties need permission to fetch the Announce'd objects and this is very difficult to achieve without having advance knowledge of all the third parties - as bearcap/token based solutions currently have issues with de-duplication of content and correctly assigning contexts. We've currently got a hybrid model in place which theoretically supports both models for public groups/forums, but it's somewhat wasteful in resources. The container/collection model can easily support both.
@mikedev @silverpill 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)?
my understanding is that conversation containers use the same id for `context` and `target`. this is redundant imo, but i suppose that's where we are currently...
@trwnh@mastodon.social @mikedev@fediversity.site as an aside, I am led to believe that 1b12 and 400e are incompatible with each other, which would preclude any implementor from simply implementing both?
Could a potential avenue be making changes to 400e so it can coexist with 1b12 — or vice versa — or is that not an option?
@trwnh@mastodon.social
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.
@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.
Thanks for the clarification. I'll take a look after another cuppa.
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?
@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.
@trwnh@mastodon.social 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.
@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.
@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?
@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
@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.
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.
@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?
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.
@julian ^ How it works in NodeBB? Do you authenticate wrapped activities?
@grishka @mikedev
@silverpill@mitra.social said in Minutes from 2 May 2024 WG Meeting:
Do you mean something like a
Announce(Note)? If it'sAnnounce(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
objectis 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.
@silverpill@mitra.social specifically for NodeBB, we don't handle non-public content yet, so we've neatly sidestepped this issue temporarily <img alt="🙂" src="https://community.nodebb.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f642.png?v=ldhb99mgg9c">
@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:
https://socialhub.activitypub.rocks/t/fep-1b12-group-federation/2724/68
@silverpill@mitra.social 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.
@grishka @mikedev
>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.
In Friendica, group participants are represented by private
followerscollection, which can be retrieved using signed fetch:https://socialhub.activitypub.rocks/ap/object/781ebb23f1080082071d0c156543eb5f
So I don't see any fundamental difference between FEP-400e and FEP-1b12. The authentication issue, however, is quite important, because without FEP-8b32 the group either doesn't scale or can impersonate anyone.
@julian
@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.