Documentation

[EisenbergEffect]

I've just found uPort, being relatively new to dApp tech. One thing that seems to be common across the dozens of dApp tech sites I've visited is that documentation is very bad. I think uPort might be what I'm looking for, but I honestly can't tell. I'm trying to build a dApp with no backend. When I read the documentation, I come across this:

---

While it is great for developers not to have a server backend to develop, it also presents many challenges.

Where do we store the user's state? How do we communicate with a user? If we have no central user database, how do we connect users together?

Our library – uPort Connect – provides solutions for most of these difficult questions.

---

Sounds very interesting. So, I quickly click on the link to learn the answers to the three questions above...and I find myself here, with no answers to those questions and a very sparse readme with little to no information about how to use the APIs and how they might be related to these questions above. As an open source project leader of 13ish years, I know it's really hard to do open source documentation well, but please, I beg of you, spend a little more time on it. If uPort is the best product for my needs, I really want to use it, but I can't determine if it will help me accomplish my goals or not. I can't see examples that mirror the scenario above at all. Can you provide any resources please?

[EisenbergEffect]

As a basic example of what I'm looking for, I'd like to see how to log in a user and then store data for that user in IPFS. When the same user logs in using uPort on another machine, I should be able to bring back the same document from IPFS that was associated with them. As a bonus, if there is some way to integrate with IPNS to allow the user to create multiple mutable documents in IPFS, associated with their uPort ID, that would be amazing. Naturally, I'd want to do all this without a backend, if possible. It's some basic scenarios like creating documents associated with a user retrieving them and updating them that no one seems to talk about anywhere. I'd really love to see some of this explained.

[localredhead]

Hi @EisenbergEffect ,

I hear your feedback loud and clear. We are working to update our documentation across the board, which the first wave of updates will be released in a few days. You can see what is upcoming by having a peak at next.uport.me. We will be developing more "Solutions" based content in the next few weeks so I'd encourage you to keep an eye out for those updates.

For your needs, it sounds like uPort can serve as an authentication layer because based on what you describe you need to tie a uPort ID to an arbitrary piece of data (ipfs address). The mechanics of how to store and pull/retrieve data is up to the implementation. I agree; examples as you mentioned would be great to see but we also want to remain agnostic to the portions that are completely dependent on the problem being solved.

Think of uPort as a collection of protocols and libraries that facilitate identity creation and the signing and verification of data related to the identity. uPort itself is less a data storage solution and more a secure message passing solution. Our technology helps facilitate the functionality you desire, and we have a team called 3Box working to provide what you mention. You'll be able to find more information at the following links, which I hope will be more helpful to you in your research.

• https://medium.com/uport/ethereum-profiles-api-54526eccd5cf
• https://github.com/uport-project/3box
• https://github.com/uport-project/3box-js

For specific examples of using uPort to authenticate, sign transactions, etc, most of our libraries have an examples folder with some helpful examples showing how to exercise some of the apis.

For uPort Connect (web/client-side authentication):

• https://github.com/uport-project/uport-connect/tree/develop/examples/integration-tutorial
  • corresponding tutorial: https://github.com/uport-project/uport-connect/blob/develop/docs/guides/tutorial.md

For uPort Credentials (Server side):

• https://github.com/uport-project/uport-credentials/tree/develop/examples
  • corresponding tutorial: https://github.com/uport-project/uport-credentials/blob/develop/docs/guides/tutorial.md

[EisenbergEffect]

Thanks for the links @localredhead ! I really appreciate it. I'll read over these during the coming days. 3Box looks particularly interesting since I've been exploring OrbitDB. Right now, I'm basically trying to figure out how to connect all the dots :) If I get something working, I'll be sure to write some tutorials and help spread the word about what you all are doing.

[EisenbergEffect]

@localredhead I read through a bunch of content but it still wasn't clear how to do a basic thing:

1. login a user with uPort (not a problem)
2. create a document on ipfs and get back a hash (not a problem)
3. associate the ipfs hash with the uPort identity (no clue how to do this)

It's that third critical step that no one seems to talk much about. So far, I can only see a few options:

1. Use a custom Solidity Contract to store a map of uPort address to ipfs hash
2. Use ENS to somehow setup predictable mappings so that it's easy to convert from a uPort name to an ENS record that points to the IPFS hash
3. Run a traditional web service to maintain the map of uPort address to ipfs hash

The first option forces a cost on my customers right out of the gate before they've even used my app and could be slow. The second option seems expensive, complicated, and slow. The third option isn't decentralized.

Option 3 seems the only practical way to make this work. Does anyone have a solution to this problem? If option 3 is the only real way, are there any references or examples showing the best way to integrate uPort and IPFS through a mapping server? It seems that 3box might be taking this approach.

[rmw2]

Hey @EisenbergEffect, Sorry this ended up on the back burner for a little while.

The questions you bring up are part of the fundamental difference between web3 and web2 thinking with respect to data storage. In particular, there is tension between data privacy and accessibility. Does the data being stored on ipfs need to be accessed by the application without direct interaction with the user? In that case, it's hard to create a completely decentralized version without one of the public options that you mentioned, or a traditional database that the app maintains. As Levi metioned, the 3box project is working on exactly this concept of "public ethereum profiles", to which you could associate an ipfs hash that stores more data, but with the ability to revoke/delete it at some later data (unlike the option 1, and more easily than option 2 above). 3box itself is built on top of ipfs and orbitdb, and just released 1.0 this week.

However, if the data only needs to be accessed by the user, with their interaction and consent, this is exactly the design of attestations on the uPort platform (sometimes referred to as credentials, verifiable claims, or verifications). These are stored on the User's device, and can be requested by the app whenever they interact with it. This is ideal if the information being stored is used to populate a UI for example, and doesn't need to be used when the user isn't present. This could replace the need for ipfs entirely, as attestations can take the form of arbitrary JSON, and can be signed by any DID to ensure the data's integrity. If there is some reason to keep the data publicly accessible, a hybrid solution could still host the data on ipfs, and store the hash with the user as an attestation.

Again, sorry for the slow response, and thanks for your continued interest.

[EisenbergEffect]

Thanks for following up @rmw2 No need to apologize. I'm sure you all are pretty busy. I've been leading open source projects for about 13yrs, so I understand :)

In my particular case, I've got two types of data:

1. Data that is private to a single user and only needs to be written or read by that user.
2. Data that is shared by a group of 4 - 6 users. All data needs to be available for all of them to read no matter which combination of them is online at a given time. While all the data is readable by the group, certain parts are writable by certain members of the group. No piece of data can be written to by more than one person. So, each piece of data has a single writer, but multiple readers.

I can model my entire application in terms of these two scenarios. In both cases, the data is accessed only via direct interaction by the user.

[rmw2]

Thanks for understanding!

So for case 1, this can be accomplished entirely with verifications -- reads are done with a disclosure request Connect.requestDisclosure(), and writes with a verification/attestation, Connect.sendVerification(). It can also definitely be accomplished with a private 3box, which has a more familiar get/set api.

For the second case, that's a much harder problem that uPort alone doesn't doesn't solve yet -- and I'm not aware of any easy solutions out there that don't also make the shared data public to the world.

I want to loop in @michaelsena who's running 3box, as this sounds like the types of problems that they're thinking about, and it could be useful to connect, (also cc @oed, who may have done some more thinking about the crypto for these types of situations).