FEP-7888

julian

@[email protected], today at fediforum I met with @[email protected] who is working on a federated photo sharing app with strong focus on privacy.

We discussed FEP 7888 and how that might address her concerns re: resolving ghost replies

So unlike me, who would implement context owner sending of Add mostly to comply with the FEP, she'll actually be wanting to start off with that part!

Jesse Karmani

@julian thank you so much for pointing me at that FEP! The discussion had seemed very forum use-case specific at first glance, but after re-reading it, I can definitely see how this applies to followers-only and circle-addressed posts and replies on @frequency

@trwnh - you mention a mastodon PR in that thread; could you point me to that? I see that mastodon is using the context for conversation threads already, but I don't think it can adjust audience of replies based on that context

julian

@[email protected] I'm glad I was able to facilitate a connection. I'm certain @[email protected] will like to hear of potentially another implementor.

The funny thing is even though our respective apps are talking ActivityPub, they're unable to talk to each other by design! Mine silently drops non-public activities, you're only accepts non-public activities. Perhaps I'm wrong about that last one haha.

One day we'll bridge our apps together!

julian

@[email protected] if however I am mistaken and Frequency can consume public activity, then please by all means use this instance as a testing endpoint.

Every post contains a resolvable context that you can use to retrieve the entire thread.

infinite love ⴳ

@jesseplusplus do you have any feedback re: the FEP? it's not meant to be strictly a forum UX thing, but rather, it applies to any case where you want to meaningfully group objects. conversationally, this would be a "thread". as a bonus, if you make that "thread" into an Object, then you can give it an audience and an owner. If you further make it into a Collection, then you can target it with Add and Remove activities.

ghost replies i'd handle by forwarding to the context's audience.

@julian

infinite love ⴳ

@jesseplusplus aside from that, I'm not sure which thread you're referring to or which "Mastodon PR" or usage. what I can tell you is that Mastodon uses an older extension property ostatus:conversation where its value is a tag: URI.

https://mastodon.social/@trwnh/113142951128143699 · BrowserPub · A browser for exploring ActivityPub and the fediverse

Explore the open social web through the lens of ActivityPub and the fediverse.

(browser.pub)

Look at the outline or JSON tabs and you can see that `conversation` is tag:mastodon.social,2024-09-13:objectId=798726780:objectType=Conversation

@julian

julian

@[email protected] @[email protected]

I think my only feedback would be potentially adding in an optional section about a context collection containing an outbox.

@[email protected] mentioned that while a context collection of objects is helpful (and I think he implemented?), an outbox would be easiest for him to keep the collection synchronized over time, vis-a-vis my ETag style synchronization header.

infinite love ⴳ

@julian

> collection containing an outbox

this is something i want to write about as well, but I'm not sure if it should be a separate FEP. probably it will be a separate FEP centered around Collection-Actors which recommends putting objects in the Collection and activities in the Actor's outbox. not sure what to call it exactly, but "collection-actor" is the provisional name for the idea.

@jesseplusplus @silverpill

Jesse Karmani

@julian frequency does in fact consume public content from other servers; we don’t restrict who people can follow, but are trying to be thoughtful about what it means when they interact with public content from elsewhere. I will definitely play around with using nodebb as a testing endpoint to see how we handle what y’all are sending! Thanks!!

Jesse Karmani

@trwnh without having tried to implement anything in the FEP yet, it looks like exactly what I would want for followers-only and circle audience post replies. One concern I have about forwarding to the context's audience in those cases is how you would handle account blocks. If I'm forwarding my reply to the context's audience, it wouldn't have any information about whether anyone in that audience is on my blocklist. Would you address it to a new collection that was context audience - blocks?

julian

@[email protected] unless you also integrate Object Integrity Proofs, you're only federating out the id of the object in Add.

So if the object author has blocked a user, when the blockee receives the Add, they'll attempt to retrieve it and come up empty. This is also assuming that Frequency has authorized fetch enabled.

@[email protected] can confirm?

Jesse Karmani

@trwnh oh sorry! I was reading https://socialhub.activitypub.rocks/t/fep-7888-demystifying-the-context-property/3021/2 and saw you mention smithereen implementing groups and a mastodon PR, but wasn't sure what that was a reference to.

Thank you, though, that's very helpful! I'll take a further look at what mastodon is currently doing with the ostatus:conversation stuff

infinite love ⴳ

@jesseplusplus I think blocks would be handled completely separately. If I send a post to a context's audience, and someone I block is in that audience, then they will receive a copy of the post. This isn't really something that can be avoided -- the audience belongs to the context, not to you. You are participating on the terms of the context's moderator or manager. A "block" just means that you will discard any post that *you* receive back from the blocked actor.

But there is a workaround...

infinite love ⴳ

@jesseplusplus The workaround is, if you specifically want for your object to not be visible to someone, then you can make that object private, send out an activity that references it only by its id, and force everyone to fetch it directly from you... then, you can implement access control however you want. This probably implies some form of cross-domain authorization or authentication, so you can make that access control decision.

infinite love ⴳ

@julian @jesseplusplus yeah, more or less exactly this. you can sub out signed fetches for any other authentication/authorization scheme, but the general principle is that if you don't want someone having a copy of the object, then don't send out the object to audiences outside of your control. sending a reference is fine.

infinite love ⴳ

@jesseplusplus ohhhhhh, i see! that PR is nothing to do with context or conversation, it's about the "groups" PR here: https://github.com/mastodon/mastodon/pull/19059

Jesse Karmani

@trwnh @julian ohh okay, this is helpful! I hadn't enabled authorized fetch or anything equivalent yet, but I see now how that allows me to still have control over who sees an object even if references to it are sent out more liberally

Jesse Karmani

@trwnh ahh, gotcha! thanks for sharing that PR

silverpill

@trwnh @jesseplusplus @julian I'm also working on a FEP, it is based on Conversation Containers and FEP-7888: https://codeberg.org/silverpill/feps/src/branch/main/171b/fep-171b.md

Still not sure about outbox and collection-actor thing. I'll try to implement Conversation Containers and obtain an informed opinion

julian

@[email protected] maybe we can press @[email protected] into service and discover what happens when instances send an Array type instead of a string.