> Will the general public learn your email address?

Yes, if you store [email protected]/dir/file and share the file path publicly then the valid email address "[email protected]" leaks out. If you own your own domain then you could have one or more email address only associated with Upspin and store at [email protected]/dir/file. The downside is the username in such paths is less recognizable to your friends than your regular email.

The reality today is anyone who uses any Google service or who has a Facebook page has an exposed @gmail.com or @facebook.com email address that can be spammed, and if he or she signs up for Upspin it's another way for it to leak out. You can use any email address that can receive the confirmation email; I'm not sure if [email protected] is a valid email address, and there's no email address with your Twitter handle.

> What happens if you switch email providers?

You would execute a new `upspin signup -dir=dir.example.com -store=store.example.com [email protected]` command, keeping the same directory and storage servers. The question is whether you can tell your directory server and storage server to reuse or alias your directory and storage to those of your previous email address.

I saw nothing about requiring email address usernames to be backed by an email provider in the documentation. The email address is literally just a username format and is authenticated by public key. Anyone concerned with the privacy of their actual email address would obviously not use that address as their user. As I understand it, you can just make one up for a username. If this is incorrect, someone more informed please reply.

The signup process sends a verification message to your email address to confirm that you own it.

Seems like that results in a different problem? Someone could take your email address.

Perhaps the new-user process requires authentication initially via email to confirm that you are in control of that address.

That is exactly how it's described in the documentation, yes.

Is their hope or stated objective to move all file sharing to this format? My takeaway was that this was designed for the use case of "trivial day-to-day sharing without hassle" (or at least that's their focus on the consumer case), i.e. taking the "another option" at face value.

Long-lived public files seem like a different use case, and one that is already generally handled okay by traditional hosting or file sharing.

They used the example of sharing on Facebook or Twitter, which are archived indefinitely, so it seems like someone should be thinking about link rot and how to avoid it?

(Should a link be shared or the data copied?)