That’s what I was thinking! But I’m not sure that is better than just randomizing the default instance. Randomizing would have almost the same effect with much less user friction.
That’s what I was thinking! But I’m not sure that is better than just randomizing the default instance. Randomizing would have almost the same effect with much less user friction.
I’m so dumb. That literally solves so many problems. I just have to confirm that works with the login endpoint. Thanks!
Edit: I’m not dumb. You can’t login with your instance at the end of the username. I also need to check if @ is a valid username character.
I’ll look into it, thanks! Maybe I’ll run it by a non technical friend and see if they get it.
What I could do is pick an instance at random and see if I can write that instance to app storage that persists on reinstall. That way, they don’t lose their account by not remembering what instance. That doesn’t solve the web.
The issue is password managers save username and password, but I need to save instance as a 3rd value. I wonder if I can prepend the instance to the front of their username in a way that the password manager picks it up, then slice it off later when they log in. But that’s kinda hacky.
Ooo yes! But I would like keep it much shorter.
Remember this is an onboarding flow for an app. It has to capture the user and explain things well without losing their attention.
What I want to avoid is “hey, select an instance from this menu”. “Wtf is an instance?”
Voyager gets around this by defaulting to an instance (lemmy.ee I think) before you log in, but my plan was to have them select when they launch the app for the first time.
After all the other comments I was thinking randomly auto select one of the instances that meets certain criteria, but you make a good argument. Giving people choice over their server was what I was initially thinking when I came up with this planet analogy.