@julian You're not wrong -- it's just generally not considered "authoritative".
Compare to DNS via the authoritative nameserver, versus DNS via a public resolver. dns:trwnh.com is different than dns://8.8.8.8/trwnh.com in that the latter is explicitly resolved via Google, or dns://1.1.1.1/trwnh.com to resolve via Cloudflare.
@Profpatsch@julian i've been doing some trust and safety TF work to explore/develop a bidirectional link between actors and moderators/hosts, yeah. mostly in the context of "where to send moderation related activities" (so you don't Flag a user to themselves if there's a better option), but also could be used for authorizing Update/Delete activities.
alternatively, the problem would not be there if service actors messaged each other for more explicit syndication...
@julian Really, taking "same origin" to its logical conclusion would mean that every actor MUST have their own origin and therefore their own FQDN. It doesn't make sense for origins hosting user-generated content unless the UGC is very tightly controlled and sanitized. And even that's not a guarantee of safety.
@julian The sending server might not have boundaries to enforce. Especially not along "same origin" lines. This requires agreement on what the authorization model is.
Say for example everyone gets a subdirectory that they "own" -- /~alice/ and /~bob/ have their spaces on the same origin. One authorization model is "anything within this container is authorized". If you don't recognize this, you can't detect that alice and bob have a boundary between them.
@julian You're making a very strong assumption that the remote server is necessarily checking for things it might not actually be checking for.
Neither the "instance" model nor the "same origin" model are enshrined in ActivityPub. This technically falls under "undefined behavior", because AP doesn't define an authorization model. (It suggests ("may") same origin, but that's about it. A lot of things are "at the receiving server's discretion".)
@julian You're not wrong -- it's just generally not considered "authoritative".
Compare to DNS via the authoritative nameserver, versus DNS via a public resolver. dns:trwnh.com is different than dns://8.8.8.8/trwnh.com in that the latter is explicitly resolved via Google, or dns://1.1.1.1/trwnh.com to resolve via Cloudflare.
@Profpatsch @julian i've been doing some trust and safety TF work to explore/develop a bidirectional link between actors and moderators/hosts, yeah. mostly in the context of "where to send moderation related activities" (so you don't Flag a user to themselves if there's a better option), but also could be used for authorizing Update/Delete activities.
alternatively, the problem would not be there if service actors messaged each other for more explicit syndication...
@julian oh dear, these couple of mentions seem not to have made it across. do i need to also mention @technical-discussion too?
@julian Really, taking "same origin" to its logical conclusion would mean that every actor MUST have their own origin and therefore their own FQDN. It doesn't make sense for origins hosting user-generated content unless the UGC is very tightly controlled and sanitized. And even that's not a guarantee of safety.
@julian The sending server might not have boundaries to enforce. Especially not along "same origin" lines. This requires agreement on what the authorization model is.
Say for example everyone gets a subdirectory that they "own" -- /~alice/ and /~bob/ have their spaces on the same origin. One authorization model is "anything within this container is authorized". If you don't recognize this, you can't detect that alice and bob have a boundary between them.
@julian You're making a very strong assumption that the remote server is necessarily checking for things it might not actually be checking for.
Neither the "instance" model nor the "same origin" model are enshrined in ActivityPub. This technically falls under "undefined behavior", because AP doesn't define an authorization model. (It suggests ("may") same origin, but that's about it. A lot of things are "at the receiving server's discretion".)