As a user, I can choose an avatar and a username for the account I’m creating.

[kikipluche]

Abstract:

In Swarm City, your identity is a public key. As we are serving real people, we want our users to be able to present themselves with a human name and a picture. This information is stored on the device in localstorage (for the avatar the IPFS hash), and only shared when the user interacts with another user or a hashtag.

How it works:

When creating a new account, the user can choose a username and avatar image. The username is simply entered in an input field. The avatar is uploaded to the DOM. The user can then scale and crop the image, and when saving, the image base64 string is sent to the API. The API adds the string to IPFS, which will return a hash. This hash is returned to the client. Together with the username, the hash is stored in Localstorage.

The user can always change their username and avatar, which encompasses the same process as the new user process.

API:

ipfsAdd

• Function ipfsAdd expects a string and returns the ipfs hash.

  {
  payload: <String> // base64 data
  }

  This function returns the ipfsHash for that payload, or 0 when error.

{
 payload: {
  ipfsHash: <String> // IPFS hash ex. "Qm......."
 }
}

If the operation errors, the API will return a 400 response code.

API documentation

---

What it looks like in front end:

has been developed

[bkawk]

When a user adds an image to their profile on the from end, a base 64 representation of the image Is stored in local storage along with the user's name and public key.

When requesting a short code the users name, public key and base 64 image of their avatar is sent to the API

Whenever the frontend needs another users avatar it will be sent from the API to the front end as a base 64 image.

The front end has no reason to make requests to IPFS directly as it would require a local IPFS node or the IPFS node on the server to be exposed to the public creating a larger attack surface, secondly making multiple IPFS requests from the front end will result in a slow loading page as each avatar to be displayed would result in a round trip to IPFS.

[kikipluche]

epic changed as decided: front end gets avatar from API

[kikipluche]

19/3 epic is clear to devteam and can be executed.

[bkawk]

Re the Base 64 image, you state: "This information is only stored on the device itself" is this only true for now or for the foreseeable future and past epics too?

[bkawk]

Reading on the spec goes on to state "The API adds the string to IPFS" which is contradictory to the statement "This information is only stored on the device itself"

[bkawk]

The statement "The API adds the string to IPFS, which will return a hash." goes against what we discussed earlier this week

[bkawk]

The statement "When we have to show the avatar, we resolve the ipfsHash to an image by calling the API to resolve the ipfs hash." I agree with but negates the need for the API to return hash

[bkawk]

I feel we should also detail the requirements for the Image upload to work on which mobile devices as this has been a sticking point in the past

[kikipluche]

@bkawk what is stored in localstorage is: the username, the ipfs hash of the avatar. So when you create or change your avatar, it has to be sent to the API who sends it to IPFS, gets a hash back and gives it to the client to store in localstorage. When the client needs to show the avatar, it will send the hash to the API, which resolves it on IPFS and send the base64 to the client. Sponnet explained in the call, how this matches the future epics.

[kikipluche]

@bkawk about the mobile devices, i feel fine with you defining how far back in time we go to serve "old" devices.

[xardass]

@kikipluche I think the way you describe it now is not how it was discussed in the last call with Sponnet. Then I remember that we agreed that the front-end wouldn't need to know about a IPFS hash, and that was purely on the API side.

[kikipluche]

in that case over to @sponnet and @kingflurkel i am fine either way, it has to be decided. How i remember it being agreed on and how i read it in the text is that the client doens't have to resolve an ipfs hash, but it does store it. Later on, the client will send this IPFS hash together with username and address to the API to make a request for example. So it will need to know the IPFShash.

But, i think it is best we have @sponnet and @kingflurkel 's input too, because we all need to be 100% clear.

[sponnet]

The reason for doing it as described in the epic is as follows

• The user sends his image data to the API ( no need for any IPFS interaction on the client side )
• The API sends back an IPFS hash
• When as a provider , you reply to a request - you can simply provide the IPFS hash instead of uploading the image again.

Benefits

• It saves bandwidth from client -> API
• It saves storage on the API

Also the agreement was discussed later on that the IPFS hashes are resolved on the API whenever you want to fetch lists of deals for example, ( images will be encoded in the reply - you will not get back an IPFS hash ) so also in this case the client does not need to resolve IPFS hashes.

So for me the ipfsCat can be left out in this epic.

I hope this resolves this discussion

[kingflurkel]

I updated the Epic according to comments / edits here.

• I changed the "only on the device itself", clarifying we store the ipfs hash for the avatar in localstorage.
• I removed IPFScat in the API section.

[eduadiez]

For me the expected behavior is clear enough, I only need to clarify a point.

The only case in which I see it necessary to have an IPFScat is if you need to restore an account. Maybe this case is part of another EPIC or in this case a default image will be used until the user uploads a new photo.

If so, I think that this line is not necessary:

When we have to show the avatar, we resolve the ipfsHash to an image by calling the API to resolve the ipfs hash. The API returns the image which can then be displayed in the front-end.

As a comment I think it would be advisable to change the name of the ipfsAdd function for something more concrete like ipfsAddAvatar or similar since it is a call with specific parameters and get a specific response.

[kingflurkel]

@eduadiez Yes indeed, the only time we need to cat is with a restore. This is part of another user story in Terminal.

I removed this line: "When we have to show the avatar, we resolve the ipfsHash to an image by calling the API to resolve the ipfs hash. The API returns the image which can then be displayed in the front-end."