<TimMc>
isd: Passwords, I suppose. Or in the other direction, nomadic identity.
<isd>
nomadic identity?
<TimMc>
Being able to move stuff to a different server and have your identity/relationships be preserved.
<TimMc>
This would be relevant if you could share documents between servers.
<isd>
Ah
<isd>
I'll probably just do something like the existing email auth to start.
<TimMc>
This is obviously all "could do" stuff, not necessary for the basic idea of Tempest.
<isd>
Yeah, auth is definitely something where I'm not going to get fancy at least until after an MVP
<isd>
Right now I'm focused on rounding out the sandbox
<TimMc>
Yeah. Just curious if there were things you had a vision of doing differently eventually.
<TimMc>
(or if this really is just "Sandstorm, but more maintainable" and nothing more at the moment)
xet7 has quit [Quit: Leaving]
<isd>
The biggest differences in assumptions are mostly around scale; the sqlite thing kindof epitomizes this. There are some small things I want to do differently, but a lot of it is stuff that isn't necessarily incompatible with Sandstorm as it exists in principle, but it just really hard to implement for $reasons
<ocdtrekkie>
Authentication and identity is probably one of the things Sandstorm probably least needs changes to, since it was designed not to have server-specific identities in the first place.
<isd>
Indeed, emails already provide stable identifiers.
<ocdtrekkie>
Same for Google/GitHub auth, though I don't know how urgent support for those should be.
<isd>
Yeah, it's not something that I consider a priority, but certainly could be added at some point
<isd>
I think the more compelling reasons to have those are things like integrating powerbox requests with OAuth APIs. But not urgent.
<isd>
E.g. stuff like importing from gcal...
<isd>
If it were just login providers it would be very low priority
<ocdtrekkie>
I like using my GitHub auth as a convenience hack because I tend to already be signed into it, but it's probably a crutch I should get away from anyways. :P