New feature from 3Box: app-specific private storage spaces https://medium.com/3box/introducing-spaces-app-specific-private-data-storage-4d75ccc2a859

that’s a nice feature @light

@dizzypaty The tagging prototype is here - https://invis.io/UGQEZZTQWHR

that’s a nice feature @light - i wonder where they store the app specific private data - encrypted on ipfs maybe?

@aquigorka thoughts on the implementation?

@jounih from the original 3box announcement post:

Data is stored on IPFS and managed via OrbitDB.

https://cdn-images-1.medium.com/max/800/0*khoc0ndjMxAvm640

we were talking about using 3box for our user identity at AraCon with @bpierre and @aquigorka. Would be worth testing it out for - if it works, we could have human readable usernames and no need for building for tagging for identity use cases

we were talking about using 3box for our user identity at AraCon with @bpierre and @aquigorka . Would be worth testing it out for - if it works, we could have human readable usernames and no need for building for tagging for identity use cases

we were talking about using 3box for our user identity at AraCon with @bpierre and @aquigorka and @dizzypaty . Would be worth testing it out for - if it works, we could have human readable usernames and no need for building for tagging for identity use cases

we were talking about using 3box for our user identity at AraCon with @bpierre and @aquigorka and @dizzypaty . Would be worth testing it out - if it works, we could have human readable usernames and no need for building for tagging for identity use cases

I don’t consider it a great naming solution (ENS seems better for this) but for storing profiles and other user data it looks like a good fit.

(The reason I say it’s not a great naming solution is because 3box profile names are not unique; this can cause issues when there are naming collisions e.g. “Which John Smith am I sending this transfer to?”)

(The reason I say it’s not a great naming solution is because 3box profile names are not unique; this can cause issues when there are naming collisions e.g. “Which John Smith am I sending this transfer to?” Whereas ENS names are each unique.)

the way ENS names are acquired I don’t think that’s a great solution for personal usernames at scale either

I don’t actually have an issue with non-unique names- you have unique avatars, and you can have other unique metadata shown on hover

the way ENS domains are acquired I don’t think that’s a great solution for personal usernames at scale either

I don’t actually have an issue with non-unique names- you have unique avatars, and you can have other unique metadata shown on hover (including the associated ethereum address)

I don’t actually have an issue with non-unique names- you have unique avatars, and you can have other unique metadata shown on hover (including the associated ethereum address)

I don’t actually have an issue with non-unique names- you have unique avatars, and you can have other unique metadata shown on click/hover (including the associated ethereum address)

I don’t actually have an issue with non-unique names- you have unique avatars, and you can have other unique metadata shown on click/hover (including the associated ethereum address). The low barrier to creating a username and associating it with a different ethereum address also makes it easy to have separate human readable identities for different DAOs (if you want)

I don’t actually have an issue with non-unique names- you have easy to distinguish avatars, and you can have other unique metadata shown on click/hover (including the associated ethereum address). The low barrier to creating a username and associating it with a different ethereum address also makes it easy to have separate human readable identities for different DAOs (if you want)

How is this an issue if we are using sub domains for users? @jounih

if we issue subdomains then it’s fine, but we’ll have to handle the metadata storage that comes out of the box with 3box (no pun)

if we issue subdomains then it’s fine, but it’s work to implement that, as well as the metadata storage that comes out of the box with 3box (no pun)

if we issue ENS subdomains then it’s fine, but it’s work to implement that, as well as the metadata storage that comes out of the box with 3box (no pun)

if we issue ENS subdomains then it’s fine, but we’ll have to implement the metadata storage that comes out of the box with 3box (no pun). All I’m saying is let’s take a look at this thing if it can get us to profiles and human readable user names quicker

if we issue ENS subdomains then it’s fine, but we’ll have to implement the metadata storage (and linking that to a profile) that comes out of the box with 3box (no pun). All I’m saying is let’s take a look at this thing if it can get us to profiles and human readable user names quicker

Agree wrt to leveraging 3box if it makes sense, just don’t think it’s an either or, we can still use ens subdomains as a unique identifier if 3box doesn’t provide that “out of the box” ;)

@jounih I’m thinking of impersonation cases where the name and profile can be duplicated. I feel like people would be more likely to catch a typo in the ENS name than notice that the Ethereum address is different. This would take usability testing to validate but given the security-sensitive nature I think it’s worth whatever reasonable cost to get this right.