AP: alternative opt in mechanisms

[sysadminpower2019]

Hello,

Castopod has native AP support but there is no way to add or follow people directly on the admin panel. So I am not sure how you could / would integrate castopod to bridgy-fed

[snarfed]

Interesting. Can you DM? If you DM yes to @[email protected], that also enables the bridge.

[sysadminpower2019]

It doesn't seem possible either. It seems to be a sorta one way app.
This is why i thought the process would something like submitting the fediverse site to the bridge site and conforming maybe via DNS changes

[snarfed]

DNS! That would be...doable, but ambitious.

Ideally, I want opt-in mechanism(s) to be:

• easy to use
• verify that you own the account
• private
• generic, ie not specific to individual servers like Castopod

So far, following and DMing satisfy these criteria. I know they're not universally supported, though, so I'm open to more ideas!

[fenarinarsa]

Same thing for Peertube and Owncast accounts. As far as I know they're notification-only so they can't opt-in.

There's also the cases of other bridges like the .makeup ones (X & Insta bridges), they can't opt-in.

[qazmlp]

There are I think only two mechanisms that are near universal for fediverse actors: The profile "summary" (bio) and posting statuses (though definitely not everything is able to post Notes).

---

The profile bio flow is easier (and I'm just using specific tokens as example, another format may be better):

• Ask the user to temporarily include some text like <Bridgy Fed: yes> in their bio.

• Let them submit their @@-handle or AP "id" in a form on the Bridgy Fed website.

• Check the profile bio, and do one of the following:

  previous state	bio token	action	response to user
  opted-out	neither	none	instruct to add <Bridgy Fed: yes> to bio, wait a minute, and retry
  either	<Bridgy Fed: no> (or both)	opt-out	confirm <Bridgy Fed: no> and opt-out, note that bridged content may disappear with a delay
  opted-in	not <Bridgy Fed: no>	profile refresh	confirm previous opt-in, present bridged handle, instruct to add <Bridgy Fed: no> and resubmit in order to opt 'back out'
  opted-out	<Bridgy Fed: yes> and not <Bridgy Fed: no>	opt-in	confirm previous opt-in, present bridged handle, instruct to add <Bridgy Fed: no> and resubmit in order to opt 'back out'

…or at least that's how I would do this, plus various error messages for other kinds of failures like not being able to fetch the actor.

Consider also opting out accounts if you see <Bridgy Fed: no> during incidental profile updates, since I think the intention is clear but the user may not remember to use the form.

Notably, bird.makeup accounts can't use this flow because it doesn't bridge the bio (but bird.makeup bridges without consent in the first place, so it's a bit ehhh).

---

For the status flow, you can do essentially the same thing, but (also) accept a link to a status in the same form.
(If you don't find tokens in the text, you probably should fall back to the author's bio automatically.)

As added complication, this would require saving the timestamp, so that no-one else can opt an account back in or out using an older status that wasn't deleted. I'd still validate the timestampe with >= in case the form accidentally gets submitted twice.

If the opt-in/-out happens via profile bio, you should probably also update the timestamp for the oldest still-acceptable control post.

[sysadminpower2019]

Would it not be possible / simpler to have someone insert a txt record in the domain and then read this txt record and be done with it

[snarfed]

That would only work for an entire instance, not for individual users, and we'd still need a way to trigger Bridgy Fed to look at that instance and the DNS record anyway.

[pcottle]

I think having a way to opt in via text in bio would be great! It'd empower individual users but not require any additional code to be written in the implementation of the server.

[Tamschi]

This would also enable some level of Threads-support. See #1210 (comment)

[snarfed]

I think #1680 has now subsumed this...?

[snarfed]

Duplicate of #1680

[snarfed]

Good news is, this is now a higher priority for us!