Nano Profile
Bring your Nano account to life
Even today, cryptocurrency wallets scare beginners. A random sequence of letters don’t seem to make any sense to most people… it is so confusing.
Improving the usability of wallets is necessary to popularize them.
And one of the great steps towards this is to give more life to the wallets, to make them more human, with a design that is intuitive, that we are used to, like names and profile picture..
This also prevents a wrong copy / paste. You know… A picture is worth a thousand words! That’s why we present you Nano Profile.
Nano Profile is a new descentralized protocol for storing and distribute profile images for Nano accounts in a P2P way.
Mix it with an interface that is simple, user-friendly and intuitive and we have the perfect combination for bringing Nano to the masses.
We are much more than a public-key, we are humans!
This innovative project was developed by me, Anarkrypto, in May, 2020 for the Nano Build-Off challenge. It is already active, but I am counting on more help from the community to make further advances!
Visit: https://nanoprofile.online
Web Demo
Before talking about technical aspects and and amaze lay users, I want to introduce you to this simple online demo interface.
How about adding a picture to your Nano account? Just choose an image, change your Nano Wallet Representative (this can be done at Natrium or any other wallet) and make a transaction using your QR Code and voilá!
The hash of your image will be permanently stored on your account and the content of the image will be replicated between IPFS nodes in a completely P2P way.
No third parties, no need for trust. Decentralization lives among us! You can change the image at any time you like.
How it Works
- The user chooses the photo he wants to display in his profile and upload it to the P2P IPFS network. It obtains the hash of the image.
- The image hash, converted to the Nano account format (nano_ + base32 (hash + blake2b_checksum (hash)).
- The user makes a transaction with with a specific amount (in raws) for the tracker account (nano_1nanoprofi1e7defau1t7account7tracker7image7registerr4twum9q3, it is a burn account without a valid private key). The account we extract from the hash is used as Representative, so he will have the hash of his image in his transaction history (onchain). Whenever he wants to change it, all he has to do it is make a new transaction.
- Other users will be able to find your registration transaction through the tracker account or by reading the transaction history of your account. Then they decode the representative, obtain the IPFS hash of the image and download the content of the image from Replicators through an IPFS node / gateway.
Replicator Node
The Replicator Node is an important component of the Nano Profile.
With it, individuals can voluntarily help to store and distribute profile images of Nano users on the network.
The Replicator node remains synchronized with the tracker account through a Nano node, used to find new images to be stored on its IPFS node.
Replicators indivuals can have their storage limit adjusted by themselves.
Install a Replicator node and make Nano Profile network even more decentralized!
Python Replicator Node:
Nano Profile Client
Integrate now into your wallet, website or other app with the NanoProfile client!:
Client side
To obtain images from other Nano accounts, you can use the client:
Support for:
- Browsers (JavaScript)
- NodeJS
This option is P2P, so you are going to need access to a Nano node and an IPFS Gateway. It is not necessary to install an IPFS node or the Replicator node.
The web demo uses this client, for example.
Server-side:
If you want to try it out using our server API, we provide you the access to it: https://api.nanoprofile.online
Example of requesting a profile image for a specific Nano account:
curl -s — header “Content-Type: application/json” — request POST — data ‘{“account”: “nano_35g1u9tcf93khx1hjdsdgo1i6eu4bty6fsc8zifo7yfn368i9nweg3zfbz5p”}’ https://nanoprofile.online
Response:
{“successful”:true, “account”:”nano_35g1u9tcf93khx1hjdsdgo1i6eu4bty6fsc8zifo7yfn368i9nweg3zfbz5p”, “blockRegister”:”709BE02EA0C4111B985A51FAA4F4D4D758AFCA6F8F0FF2972EAAC8CF6F420DB3", “imageHash”:”QmaBvRuuYgX5nsJfKvLuJo3eDDTJUhuiUCwE7kT5gsbCgY”, “imageLink”:”https://ipfs.io/ipfs/QmaBvRuuYgX5nsJfKvLuJo3eDDTJUhuiUCwE7kT5gsbCgY", “imageSize”:57589, “localTimestamp”:”1589995691"}
You can also make these requests on your own Nano Profile Replicator
Technical informations
Indexing images decentrally
Although the simplest solution would be making an API using a central server with an SQL database, such centralized solution is far from being an ideal model, since centralized systems are incompatible with decentralized cryptocurrencies like Nano.
In this document, I explain in details the creation of a new P2P protocol that uses a mechanism completely decentralized and distributed in order to offers such features to users, using Nano transactions + a P2P network (IPFS).
First, I would like to briefly explain what IPFS is:
The IPFS (InterPlanetary File System) is a P2P network, similar to the BitTorrent protocol, however it brings about some extra utilities. Anyone can run a node on the IPFS network and exchange files there in a Peer-to-Peer manner. IPFS connects all peers (nodes), through the DHT system (Distributed Hash Table), allowing requests for a certain content to be found in the nodes that stores them and sent to those who request them. IPFS, like Nano, is based on a DAG model (Directed Acyclic Graph) and has become very popular as a P2P communication network used in decentralized projects. Among them I can quote:
- OpenBazaar: a decentralized virtual market
- Everypédia: A decentralized Wikipedia that is supported by IPFS and rewards content creators with tokens
- DTube: A distributed alternative to YouTube
- Idorse: A decentralized alternative to Linkedin
IPFS has also been widely used for the creation of Dapps, using its power to provide files in a P2P manner with smart contract platforms.
It is possible to access IPFS files using a browser, without installing anything, through Gateways. There are several public gateways on the IPFS network that you can use for this purpose, for example:
- https://cloudflare-ipfs.com/ipfs/QmaBvRuuYgX5nsJfKvLuJo3eDDTJUhuiUCwE7kT5gsbCgY
- https://ipfs.io/ipfs/QmaBvRuuYgX5nsJfKvLuJo3eDDTJUhuiUCwE7kT5gsbCgY
- https://ipfs.infura.io/ipfs/QmaBvRuuYgX5nsJfKvLuJo3eDDTJUhuiUCwE7kT5gsbCgY
For more information, visit https://ipfs.io
Advantages of using Nano + IPFS:
- The association between files and Nano accounts enables a vast number of applications to be developed
- Take advantages of the asymmetric signature used by Nano accounts for authentication
- Use Nano’s decentralization features to our advantage: the Nano ledger is safe and incensurable, transactions are permanent.
- Proof of Work involved in Nano transactions discourages spams.
- Nano, being a crypto asset itself, can be used as financial asset for such applications, offering its advantages related to instantaneability, zero fee, scalability, simplicity and decentralization.
Taking into consideration that some cryptocurrencies projects already take advantage of the IPFS technology, I believe that we can do the same using Nano. And with all the advantages of a cryptocurrency such as Nano.
What matters to us now is that on IPFS, just like on BitTorrent, every file is identified by a single immutable hash (the file’s checksum).
For example, this cat picture (cat.jpg) has this hash:
Qmd286K6pohQcTKYqnS1YhWrCiS4gz7Xi34sdwMe9USZ7u
This hash is simply the 32-byte sha256 checksum of the file, encoded in base58 and with a prefix added to it.
As a Nano public key also has 32 bytes, here we have an excellent opportunity to be intelligently explored: an efficient and secure way to store files in our favorite cryptocurrency, without damaging Nano.
We can index this image or any other file within a single Nano transaction. We just need to store her HASH in the transaction.
To do this, we encode the 32 bytes of the hash into the Nano format:
nano_ + base32_encode (hashKey + blake2b_checksum (hashKey))
Then, we can use the Nano account generated in the representative field.
To obtain the IPFS hash again, just decode the 32-byte key and encode it in the IPFS multihash format:
base58 (hex (12 20) + hashKey)
Keeping Replicators in sync with the most recent image
The advantage we get when placing a universal account (tracker account) in the destination is that it will allow Replicators to find the images and host it for users on their IPFS nodes. Thus, users do not need to run their own IPFS nodes to have their images online … the Replicators’ P2P network will do this for them.
It is also important to allow users to change their profile image if they want to, for this the Replicators will need to keep themselves synchronized with the registration account and the user account.
The registration account is a burn account, without a valid private key, and all transactions sent there are marked as “pending”. When we read the pending transactions for an account, we do not know which one came first, as Nano transactions does not involve Timestamp, that is, the transactions do not carry information related to the time and date on which the they were made. Instead, Nano uses a DAG technology in which the blocks connect to each other synchronously. Example: block 3 connects to 2, which connects to 1 and so on. We soon know which transaction came first / last. However, this can only be done by reading the transaction history of an account.
So, when a user changes his profile picture to a new one, the Replicators search for new transactions in the registration account and extract from them the accounts that were sent to, after that they read the transaction history of these accounts and find the last image registration transaction and the image in it becomes his current profile picture.
Managing the storage
As it is a decentralized and “free of charge” system that hosts images, Replicators must adopt storage limits.
Images will only be saved by Replicators if they have 256 kilobytes or less, which is more than enough for a 500x500 image in jpeg. This limit is ideal for a profile picture. An image compressor may be a good solution for users who would like to upload an image larger than this.
256KB is also perfect for being the size of an IPFS chunk.
Still, if there is a significant number of users using this system, the Repicator would need to provide more space for storage. To avoid this, the API Replicator will be adjusted with a limit of 5GB. Enough to store at least 19531 256KB images.
Replicators with more storage space to offer can change the settings using the config.json file.
Replicator nodes incentives
New replicators nodes is useful for keeping user images distributed over the network. And that should be the main incentive for someone to install a replicator node.
Developers and users who make use of NanoProfile, therefore, are the main stakeholders in principle.
But in addition, it is possible to mention other incentives:
NanoProfile makes Nano deflationary, as each image register burns a certain amount of Nano. This is a benefit for the Nano stakeholders.
Users will be able to encourage Replicators who install the Replicator node and make it available on the network with their IPFS nodes. Through a web panel they will be able to see the nodes online and donate Nano to them.
Although it is voluntary, the Replicators’s node can be configured to prioritize storage for those accounts that donated. Something simple to do.
Avoiding SPAM
There may be agents interested in improperly consuming Replicator’s storages. Although the incentives for such an action are low, we must take it into consideration.
The first disincentive for doing this is the Proof of Work of Nano transactions. Since to store any image you will need to make a Nano transaction using proof of work, your potential is limited. So, just like Nano discourages spam with PoW, this mechanism is integrated here natively too.
In addition, each account can only host a single image. Anyone interested in storing more than one would need to create multiple accounts, transact to them, unlock the balance and make another transaction. So even more proof of work would be required.
The mechanism that allows Replicators to prioritize those who donated to their node also free users who donated from such concerns, as they will be prioritized.
And, last but not least, if necessary, we can discourage spam even more in the future by making image registers more expensive with the following possible techniques:
- Requiring a greater burning of raws in the image registration transaction (suppose 0.001 Nano). The raw code that identifies the transaction can be used in the last decimals.
- Demanding more proof of work for image registration transactions (10X, 20X, 50X and etc.). Something that requires more hardware / time from users but is easy to be checked by replicators.
The choice of which method is most appropriate will be made soon with the support of the community and implemented in the next version of the Replicator node
Blacklists: Eliminating inappropriate content
Some users might want to host inappropriate images on the network.
In centralized systems there are moderators with the power to delete such content and ban users. But in our case, as it is a decentralized model, the approach to this problem must be different.
There are at least two possible approaches to solving this problem, both are voluntary and involve the creation of blacklists:
- Individual: Each Replicator has the power to edit its blacklist, banning accounts that try to register inappropriate content and auto-deleting the content on its node. The same filter can be applied on the clients side.
- Delegate: Replicators and clients can delegate this task to third parties, just as Nano users delegate their voting power to Representatives. Reputation systems based on trust or on stake can be applied decentrally. Perhaps the easiest way to transmit the blacklist is using an IPNS, which allows us to create dynamic files, like lists, in IPFS
Nano Profile Client and Nano Profile Replicator nodes already has a blacklist includes. Just add the accounts, ipfs hashs or blocks to be removed and they will not be shown through the API; on replicators the images are deleted. Each user or application provider can create their own blacklist. In the web demo there is constant monitoring and a blacklist applied.
The delegated moderation system is under development and will be implemented soon for voluntary use.
Privacy
It is common to be concerned that this tool may eliminate the privacy features that many people look for in cryptocurrencies. After all, users can use it to upload real photos of themselves.
However, users are by no means obligated to upload pictures showing themselves or any private information. They can simply choose a picture that represents themselves, for example… It can be a logo, a character, an avatar, an emoji, an animal, an object and etc.
Therefore, this is an excellent tool not only for companies and public people, but also individuals looking for privacy.
######
I thank Nano Build-Off for the opportunity and I count on the help of the community for this project to grow even more!
For updates, questions or suggestions, join our Discord channel!
Nano Donations:
Follow me (Anarkrypto) on:
#decentralization #nanocurrency
########
¹ We can obtain the timestamp of a transaction through the nodes, but this information only refers to the moment when that particular node obtained such a transaction and this varies from node to node, specially for nodes which synchronized with the network later
