FEP-7888

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.

infinite love ⴳ

@julian @silverpill @helge that would be useful information to have but you don’t actually need to make collection-actors into multityped objects, although it would be useful to define and multitype against some type(s) that described how the actor operates. But for now it can just be a Collection with inbox+outbox+followers. Later it can be a [Collection, Conversation, Context, Whatever]

infinite love ⴳ

@julian To expand on that last bit:

- Collection = an AS2 Collection. (implied to have properties like items or first/last)
- Conversation = specifically contains objects with `content` (these contentful objects represent “posts”)
- Context = an `attributedTo` actor will Add objects that it encounters where `context` points to the current object (can be manually managed or auto or even self managed)
- Whatever = some extension type for some other use case

cc @silverpill