Authenticator pattern is at odds with permissionless goals

[olizilla]

The Authenticator as a "you must log in to see this" pattern is a left-over from web2 and a previous iteration of the w3 apis.

Everything we are building allows participants to do things locally without registering. We currently require people to register an email address to associate with a space, but this is changing as we iterate on the specs

For example, we could remove the authenticator step from w3console and the app would let you make spaces as it does now. No need to prove anything to the website before you start using it.

[olizilla]

Noting that @alanshaw flagged this a few weeks ago, and I increasingly agree.

[olizilla]

If we wish to keep it then we need to explore how to make it easier to customize. How would I put a logo on it for the app it's being used with? Should it manage the full screen covering div or could we reduce it's scope to register box, so calling code can decide how to render the auth step.

[alanshaw]

Yeah I'd like a user to get all the way to uploading a file before being asked to verify an email address.

[travis]

Huge +1 - @gobengo and I were talking about this last week and I think @jchris is all the way there too.

It feels like we should lean into communicating to the user what's actually happening here - you can create as many spaces as you want without telling us about them, and potentially even upload some/small files* before registration, and we'd have some sort of UI explaining the limitations of unregistered spaces** perhaps?

This would definitely change the structure of the w3ui components and w3console, but it feels like a good direction to me.

*maybe? lotta considerations here - how big do we let files get? would allowing uploads without an email attached have legal implications? could we store uploads in local storage and then sync them all up once a space is registered?

** ?