Pending follow requests

[onethingwelldev]

Hi,

I'm experimenting with bridgy-fed. For some reason, all my follow requests from Mastodon instances are ending up in a pending state ("Cancel follow" button). Any ideas what could be wrong?

[snarfed]

Thanks for the report! Looks like maybe a bug on Bridgy Fed's end. I'll keep you posted.

[snarfed]

@onethingwelldev I think I've fixed this. Let me know if follows get accepted now!

[onethingwelldev]

It works now, thank you! I'll try to experiment a bit more with BF.

btw. thank you for creating this awesome project.

[onethingwelldev]

Thank you.

btw. is it possible to make my BF user page (i.e. https://fed.brid.gy/web/domain) private?

[snarfed]

Hmm! Not right now, but I'd love to learn more. https://fed.brid.gy/robots.txt already blocks search engines from indexing user pages, and everything on your user page(s) is already publicly visible on your site and/or in the fediverse. Is there something specific you're hoping to hide? Or just generally minimizing visibility?

(I'm very open to the idea! Just curious to understand it more.)

[snarfed]

One key point here is that Bridgy Fed has no real login system per se right now. I could add one, but I'm reluctant to.

There are a few alternatives. I could use IndieAuth, but that only works for web site users, and it's not widely adopted yet. I could serve your user page on an unguessable URL, which could be ok. I could serve it with a password via HTTP Basic Auth, but I'd rather avoid passwords since they immediately beg for a way to change them, which is effectively an account login system.

[onethingwelldev]

I asked that mainly because I noticed that my user page is now full of test events, which I can't remove. But I imagine people may also have other concerns with the public historical log of all these events (e.g. if someone follows me, and then unfollows me, are they okay with the log of that being forever publicly displayed on my profile page?).

Regarding the authentication method, I guess IndieAuth makes the most sense, since some parts of the page already require it (and you need to have a website to use BF anyway). Overall, I don't think this is a super high-priority feature, but it may be worth considering for some future version?

[snarfed]

Got it! Yeah, that historical event log is already fully publicly available in AP, but the friction of not showing it in a UI can definitely still count. I could hide sensitive events like unfollows and deletes, but the main use case for the pages right now is user-level debugging, which those events are useful for.

Re auth, the catch is that BF will soon be multi-protocol, ie usable by people on the fediverse and other networks like Bluesky, so I'd need an auth mechanism that works for all of them.

I may start by letting people request to disable it entirely for their account(s). Filed #769 for that, thanks for the nudge!

[onethingwelldev]

Got it! Yeah, that historical event log is already fully publicly available in AP, but the friction of not showing it in a UI can definitely still count.

I'm not sure I understand what exactly you meant. Are you saying that it's possible to get the full historical event log from the BF AP server, not just subscribe to current events? (because those are two very different things)

Re auth, the catch is that BF will soon be multi-protocol, ie usable by people on the fediverse and other networks like Bluesky, so I'd need an auth mechanism that works for all of them.

But you'd still need to have your own site to be able to bridge it to bsky, right? is there any reason why IndieAuth wouldn't work in that case?

I may start by letting people request to disable it entirely for their account(s). Filed #769 for that, thanks for the nudge!

I think IndieAuth may be a better option than disabling the page completely (these logs can be still very useful for debugging), but it's quite possible that I'm missing some context on that.

[snarfed]

I'm not sure I understand what exactly you meant. Are you saying that it's possible to get the full historical event log from the BF AP server, not just subscribe to current events? (because those are two very different things)

Ah, no, I'm saying that independent of BF, you can often get historical event logs in the fediverse, including Delete and Undo activities. Here's an example Delete BF received recently that's fetchable with AS2 conneg Accept header and a valid HTTP sig: https://ack.nerdfight.online/activities/2c4929ee-1016-4617-8935-e897046f83b4 . Deletes and Undos are also delivered very widely, often to every known instance, including single-user instances, so they're accessible to many users in general.

Regardless, you're right that friction counts, and an option to hide this in BF's UI definitely makes sense!

[onethingwelldev]

Ah, yes, although these Akkoma activities urls are transient in nature, and should expire after some time, there are no guarantees that they won't get permanently stored somewhere else. But yeah, it's about the friction, and with follow/unfollow activities, there's even more friction.

[snarfed]

But you'd still need to have your own site to be able to bridge it to bsky, right? is there any reason why IndieAuth wouldn't work in that case?

Nope, the plan is to bridge any two supported protocols directly, bidirectionally, eg fediverse <=> Bluesky (once they enable federation and I ship it). So I'm mostly avoiding auth for now because I'd rather not maintain multiple login systems.

[onethingwelldev]

I see... That was the part I was missing, this definitely makes auth more tricky.