Skip to main content


This web based onboarding UX for #Piefed is perilously close to my suggestion as to how to fix fediverse onboarding that I made back in June.

(IIt seems to lack round robin in place, but other than that, it has a simple, single main choice clearly featured UX placement, but with an offramp to a more complex wizard for those who want one)

cc: @rimu
timothychambers.net/2025/06/24…

This entry was edited (3 months ago)
in reply to Tim Chambers

basically the perfect UX for most complex tasks and it’s amazing it’s not used more often.
in reply to Tim Chambers

One note would be to make the form elements underneath invisible or greyed out unless users chose the "I don't know, help me" choice... But well done.
in reply to Tim Chambers

Cheers :)

I'm hoping to maximize the dispersal of new user across all the instances so wanted to keep other options visible from the beginning.

Can't wait to roll this out more widely. A key part of it is that it's built-in to every #PieFed instance, not a separate web site. So it's power comes from everyone being on board.

crust.piefed.social/auth/insta…

Tim Chambers reshared this.

in reply to Rimu

how do you build this list? Is this a directory server admins can opt into? Do you do any filtering / verification?
in reply to Renaud Chaput

@renchap It is opt in, yes.

The master list of PieFed instances is retrieved from the fediverse.observer API. Then an API endpoint on every instance in the list is queried to see if they opted in and to get information about the instance that fediverse.observer does not have.

This happens once per day.

Instance admins can choose to filter out any other instance and defederated ones are automatically filtered.

in reply to Rimu

@rimu @renchap The idea that it is built into the UX of every #piefed server itself is also interesting.
in reply to Tim Chambers

Yes it is, but I am worried about letting users pick their server from any server that opt in. You really want users to go on *well-managed servers* and avoid servers that depend on a unique person (high risk of the server disappearing), without proper moderation or correct operation practices. And that is without even without discussing about bad actors starting to exploit this.
in reply to Renaud Chaput

@renchap @rimu For Mastodon I could imagine it being those that signed the Server Covenant, and in my original straw man idea I suggested other site quality metrics….(uptime over last X years, etc) docs.google.com/document/d/18k…
in reply to Tim Chambers

The server covenant is purely declarative, I think that if we start sending the general public to a pool of servers there needs to be more checks here. But we have ideas in this area that I hope we will soon be able to make progress on.

Tim Chambers reshared this.

in reply to Tim Chambers

maybe there's a FEP that can be done to expose these attributes somehow to enable the suggested servers be "those you federate with" along with filtering & like number of relationships/interactions?