If the context owner refuses to acknowledge any and all incoming replies, the thread is effectively locked.
The approach seems like it would pair well with either interaction policies on the context object and/or a FEP-c0d0-like flag, so actors can know in advance which kinds of activities are likely to succeed or fail, i.e. so UI hints can be provided (grayed out buttons etc).
@julian@activitypub.space Thank you! Yes, the context-level interaction controls (we talked about them briefly near the start of the year) will most likely not be part of v1 of my document.
In my draft text I leave it open whether an interaction constraint is imposed by the post author or a moderator. Maybe this distinction should be explicit.
@mkljczk Hmm, true! Is that something a setup like this would run into? I would think the name part of the handle would still be fully governed by the ActivityPub server, which could enforce its own uniqueness constraints.
@julian@activitypub.space I haven't fully thought through the ramifications, but it would be slightly simpler (for situations other than mere static file hosting) to ask the WebFinger domain owner to set up an HTTP redirect for /.well-known/webfinger back to the ActivityPub server. The ActivityPub server could then do an ACME-like (as in Let's Encrypt) challenge to check that this redirect is in place, and if so, proceed to serve the correct WebFinger payload itself.
@mkljczk The service domain thing has the advantage that the chosen domain works even with servers that don't respect split-domain setups, but I don't know if I would bother with it just for that advantage. Why does the other way need host-meta?
Would be incredibly cool to see per-account WebFinger-based custom handle domains in a major platform!
Even they don't go all the way, they “only” let server admins add a selection of WebFinger domains for users to choose from.
So what if we put a “handle domain” field into people's account settings, let them enter whatever they want, and on submission we test whether that domain's WebFinger query for the username in question returns a valid result pointing back to our local actor?
Notably, everyone so far other than Takahē treats this as a server-level configuration, when it would work perfectly fine as a per-account setting. I've had a FediForum demo titled “None of you have any idea how close we already are to custom handle domains in profile settings” drafted in my head for years, I just can't find the time to put it together.
Note the self link and the subject. In a split-domain setup, the WebFinger results for both hostnames are identical, which is why server software often simply issues an HTTP redirect for ease of implementation.
For clarity, I didn't invent this, Mastodon came up with it (and respects it for profile views). I noticed while setting up earlier versions of @DailyRucks that Misskey does not. And so @canary was born. 😉
@julian@activitypub.space Current split-domain setups (Mastodon, GTS etc) do the two-way verification like this: the domain A WebFinger result has a rel="self" ActivityPub link pointing to the actor on domain B, the domain B WebFinger query for user@domainB returns a result with subject: user@domainA. The actor document doesn't need to do anything special.
That said, FEP-2c59 has seen some uptake since I wrote @canary. I should update the text some time to reference it.
@julian@activitypub.space@wronglang Only kind of – I've never considered the implications of a server resolving a WebFinger query for a user on a different origin. At a glance I'm not sure if it solves more problems than it introduces.
@stefan@stefanbohacek.online Nice work! 🙂👍 Your demo kicked off a conversation in the WeDistribute Matrix room, where it turns out a number of people have also been working on similar things. (My own design notes look like this: https://stuff.jfietkau.me/starter-packs) Some of us are now trying to maybe join forces.
It was a good episode to round out the prep phase of the current conflict. Plenty of potential for the next cour to bring lots of action and interesting tactics. I'm glad we don't have to wait too long. 🙂
And yeah, the Byakuya parts were very moving, if maybe a bit heavy-handed. Though I appreciate the show is sticking to what it knows best by keeping the characters relatively simple.
(Btw: upvoting and commenting from Mastodon. I wanna see how well this works.)
@julian@activitypub.space @silverpill I believe it's mainly this: https://codeberg.org/fediverse/fep/src/branch/main/fep/171b/fep-171b.md#moderation
If the context owner refuses to acknowledge any and all incoming replies, the thread is effectively locked.
The approach seems like it would pair well with either interaction policies on the context object and/or a FEP-c0d0-like flag, so actors can know in advance which kinds of activities are likely to succeed or fail, i.e. so UI hints can be provided (grayed out buttons etc).
@julian@activitypub.space Perfect, that's what I figured. Thanks again, and let's keep in touch about the topic.
@julian@activitypub.space Thank you! Yes, the context-level interaction controls (we talked about them briefly near the start of the year) will most likely not be part of v1 of my document.
I am still curious whether a FEP-c0d0 lock and the interaction policy you posted are indeed equivalent given these conditions: https://docs.gotosocial.org/en/latest/federation/interaction/_controls/#implicit-assumptions I'm assuming no.
In my draft text I leave it open whether an interaction constraint is imposed by the post author or a moderator. Maybe this distinction should be explicit.
@julian@activitypub.space There is potential overlap with interaction policies here. Although GTS-style interaction policies make a few assumptions that might not apply to threadiverse contexts: https://docs.gotosocial.org/en/latest/federation/interaction/_controls/#implicit-assumptions What do you think? Maybe FEP-c0d0 is a “harder” lock.
People can still like and share locked threads, yes?
Off topic: My outline for the interaction controls work in the T&S task force mentions context-aware policies as a tentative non-goal. https://github.com/swicg/activitypub-trust-and-safety/issues/159#issuecomment-5348012095 NodeBB gets a shoutout.
https://docs.gotosocial.org/en/latest/federation/interaction_controls/#implicit-assumptions
@julian@activitypub.space Yo @by_caballero if I recall correctly this was a passion topic of yours, check out this fun thread!
@mkljczk Hmm, true! Is that something a setup like this would run into? I would think the name part of the handle would still be fully governed by the ActivityPub server, which could enforce its own uniqueness constraints.
@julian@activitypub.space
@julian@activitypub.space I haven't fully thought through the ramifications, but it would be slightly simpler (for situations other than mere static file hosting) to ask the WebFinger domain owner to set up an HTTP redirect for /.well-known/webfinger back to the ActivityPub server. The ActivityPub server could then do an ACME-like (as in Let's Encrypt) challenge to check that this redirect is in place, and if so, proceed to serve the correct WebFinger payload itself.
@mkljczk The service domain thing has the advantage that the chosen domain works even with servers that don't respect split-domain setups, but I don't know if I would bother with it just for that advantage. Why does the other way need host-meta?
Would be incredibly cool to see per-account WebFinger-based custom handle domains in a major platform!
@julian@activitypub.space
@julian@activitypub.space Here's what Takahē has to say on the subject: https://docs.jointakahe.org/en/latest/domains/
Even they don't go all the way, they “only” let server admins add a selection of WebFinger domains for users to choose from.
So what if we put a “handle domain” field into people's account settings, let them enter whatever they want, and on submission we test whether that domain's WebFinger query for the username in question returns a valid result pointing back to our local actor?
I honestly think this would work.
@julian@activitypub.space Here's Mastodon's server admin documentation for the feature: https://docs.joinmastodon.org/admin/config/#web_domain And here's GoToSocial's: https://docs.gotosocial.org/en/latest/advanced/host-account-domain/
Notably, everyone so far other than Takahē treats this as a server-level configuration, when it would work perfectly fine as a per-account setting. I've had a FediForum demo titled “None of you have any idea how close we already are to custom handle domains in profile settings” drafted in my head for years, I just can't find the time to put it together.
@julian@activitypub.space Yep! Compare
https://correct.webfinger-canary.fietkau.software/.well-known/webfinger?resource=acct%3Acanary%40correct.webfinger-canary.fietkau.software
and
https://wrong.webfinger-canary.fietkau.software/.well-known/webfinger?resource=acct%3Acanary%40wrong.webfinger-canary.fietkau.software
Note the self link and the subject. In a split-domain setup, the WebFinger results for both hostnames are identical, which is why server software often simply issues an HTTP redirect for ease of implementation.
For clarity, I didn't invent this, Mastodon came up with it (and respects it for profile views). I noticed while setting up earlier versions of @DailyRucks that Misskey does not. And so @canary was born. 😉
@julian@activitypub.space Current split-domain setups (Mastodon, GTS etc) do the two-way verification like this: the domain A WebFinger result has a rel="self" ActivityPub link pointing to the actor on domain B, the domain B WebFinger query for user@domainB returns a result with subject: user@domainA. The actor document doesn't need to do anything special.
That said, FEP-2c59 has seen some uptake since I wrote @canary. I should update the text some time to reference it.
@julian@activitypub.space @wronglang Only kind of – I've never considered the implications of a server resolving a WebFinger query for a user on a different origin. At a glance I'm not sure if it solves more problems than it introduces.
What we do have is WebFinger results linking to ActivityPub actors on a different domain. Fun for things like static site redirects: https://www.hanselman.com/blog/use-your-own-user-domain-for-mastodon-discoverability-with-the-webfinger-protocol-without-hosting-a-server And it enables split-domain setups if the ActivityPub domain delegates its WebFinger lookups back to the WebFinger server.
@stefan@stefanbohacek.online Nice work! 🙂👍 Your demo kicked off a conversation in the WeDistribute Matrix room, where it turns out a number of people have also been working on similar things. (My own design notes look like this: https://stuff.jfietkau.me/starter-packs) Some of us are now trying to maybe join forces.
It was a good episode to round out the prep phase of the current conflict. Plenty of potential for the next cour to bring lots of action and interesting tactics. I'm glad we don't have to wait too long. 🙂
And yeah, the Byakuya parts were very moving, if maybe a bit heavy-handed. Though I appreciate the show is sticking to what it knows best by keeping the characters relatively simple.
(Btw: upvoting and commenting from Mastodon. I wanna see how well this works.)