@trwnh@mastodon.social, today at fediforum I met with @jesseplusplus@mastodon.social 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!

@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

@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

@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

@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?

@jesseplusplus@mastodon.social 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.

@trwnh@mastodon.social can confirm?

@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

@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...

@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.

@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.

@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

@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

@trwnh ahh, gotcha! thanks for sharing that PR