How Nano Digital Money Could Be Integrated Into a Large Social Network

Note: the following article originally appeared as a series of tweets on the NanoCharts X/Twitter account.

Part I: Users & Nano Addresses

Nano is a digital currency that is suited for microtransactions due to the fact that it charges zero fees. This makes it perfect for social network functionality such as tipping content creators. What could a social network integration of Nano look like?

Please note: this is just a high-level view of a Nano integration without intimate knowledge of how each social network organizes its infrastructure. It's generic enough that it could be used for any large-size social network but ultimately likely an over-simplification.

The User is at the heart of a social network ❤️ Each User will have an associated User Record in the social network's distributed database infrastructure. This will be for storing data associated about the User such as username, email address, etc...

To allow sending and receiving of nano a User will need a Nano Address. These addresses are prefixed with "nano_". Here is an example of how one looks: nano_3xxy9ck34es735n5y3388eibsqbqg31r9at5s4o71gnmubox3sfqrj4771m7

Each User will likely only need one single Nano Address to receive and send nano from. This Nano Address should be retrievable from the User Record when needed just like other data.

The Private Key for a Nano Address should be stored in the User Record, likely with extra security mechanisms to protect this sensitive information. If a Nano Private Key is ever leaked anyone can control the associated Nano Address fully.

To create a Private Key the social network infrastructure will need to interact with the Nano node software which interfaces with the Nano network.

Node interaction takes place via RPC commands on a machine running a Nano node. Nano Node RPC command "key_create" is used to generate a random Private Key along with its associated Nano Address.

A User's Nano Private Key could be created when they are first sent some nano by another User on the social network or when they first attempt to check their nano balance via the social network's UI (allowing a few seconds for Private Key creation and saving to User Record).

Only the Private Key should be stored in the User Record, although for convenience the derived Nano Address can also be stored.

However it's not mandatory as the Nano Address can always be derived from the Private Key as needed (using the Node RPC command "key_expand").

That covers creation of a User's Nano Address. Next we will look at how the social network might interact with the Nano network for the benefit of its Users e.g. tipping content creators.

Part II: Sending Nano between Users

Now that each User has a Nano Address, a whole new suite of functionality can be unlocked on the social network by transferring value between Nano Addresses over the Nano network. We will look at a really useful one - Tipping other Users!

Imagine a Tip icon appears under each social network post. Clicking it would start the process whereby you can reward the User for the content they shared in the post.

Upon clicking the icon, a screen appears to let you specify how much you would like to Tip to the User. While the Nano network is being used to handle the value transfer, the UI could instead display fiat currency denominations instead of nano and switch back before sending.

In order to know the User's nano balance that is available for Tipping, the User's Nano Address needs to be queried using the Nano Node RPC command "account_balance". The User's Nano Address can be read from the social network User Record.

In this example, a $1 amount is chosen as a Tip. When the user confirms this is want they want to send, the $1 is translated into its equivalent nano amount by consulting with an external API for current market rates of Nano-to-USD.

Confirmations on the Nano network take under one second on average, so there is little chance for the market rate of Nano-to-USD to change significantly during this tiny timeframe.

To send nano from any given Nano Address, a Send block needs to be constructed and broadcast to the Nano network. For this the Nano Node RPC command "process" can be used.

Some data fields of interest in the "process" RPC request are "link" and "work". The "link" field needs to populated with the Nano Address Public Key (derived from Private Key) of the User that will receive the nano Tip.

The "work" field is populated with a hash that is calculated as an anti-spam measure for the Nano network. The Nano Node RPC command "work_generate" is used to generate this small Proof-of-Work.

Constructing the rest of the Send block is a little outside the scope of this thread but you can find more detailed information in the very useful Nano Docs for Send block.

Returning to the Tipping UI - once the Send block is processed and confirmed on the Nano network the social network can send a notification to the sending User to let them know their Tip was successful.

And on the other end, the receiving User gets a notification that some nano (or fiat-translated equivalent) has arrived in their Wallet, or to be more precise when a nano amount is detected for the User to receive.

These notifications for the sending and the receiving Users respectively should ideally be triggered by the websockets functionality of the Nano node software, which can be utilized to watch for specific network activity and are very fast.

Nano sent on the Nano network is not actually received until the receiving Nano Address publishes a corresponding Receive block for the Send block. For the social network to construct the Receive block it needs some intent from the User to do so.

This intent could be triggered by the User visiting their Wallet page on the social network. When this happens Receive blocks for corresponding Send blocks could automatically be constructed and sent to the network.

Once the Receive block/s are confirmed on the Nano network (confirmations take less than a second on average) the Wallet UI can update to show the User's current nano balance.

The Receiving User now has nano in their Nano Address that they can use to Tip other Users and the cycle can repeat itself 🔁 Imagine the impact to empower content creators that Tips would have! Nano can enable many such functionalities.

That covers sending nano between Users on the social network. Next we will look at how the social network's infrastructure can be better organized to interact with the Nano network at scale.

Part III: Infrastructure and Scaling Considerations

If you are familiar with developing with Nano you may have found it unusual that up until now we didn't make use of more common wallet RPC calls such as "account_create".

When working with a single Nano node it makes sense to use RPC call "account_create" to add new accounts deterministically into the wallet. As there is only a single Nano node, the Nano Address can be added to the node's wallet. This works fine for smaller apps or services.

However if you are running multiple Nano nodes, as a large social network likely would, this won't scale very well. Your Nano Address will need to live independently of any one Nano node's wallet.

To work across multiple Nano nodes it may be best to query any of the Nano nodes for the data that will be required for a block, construct the block in a custom piece of code, and finally send the block to any of the Nano nodes for broadcast to the Nano network.

This way of constructing and broadcasting blocks means that a Nano Address doesn't need to live on any one Nano node, and is a less stateful way of handling Nano Addresses and transactions between them.

A Nano Address can be read from the User's Record in the social network.

Nano Addresses living independent of any one Nano node allows for the addition or removal of Nano nodes to/from a load-balanced group of Nano nodes as required.

Adding more Nano nodes to a load-balanced group is important as the userbase of a social network grows, and more Nano-related activity takes place between Users.

In a similar fashion to having a group of Nano nodes to handle interaction with the Nano network, a load-balanced group of PoW (proof-of-work) generation machines (for Nano's anti-spam PoW) could also be used.

It should be noted that Nano nodes that provide nano-related functionality to the social network should have voting disabled. This means they are used for interaction with the Nano network only, and not for consensus purposes.

Using a Nano node for both non-voting and voting (consensus) purposes is discouraged as it puts more computational and network bandwidth strain on the node in question. Specifying which role it should play is set in its configuration file, where voting can be set to disabled.

That's not to say that the social network shouldn't run a special Nano node strictly for voting purposes. Running such a Nano node is encouraged, especially for services/apps who care about promoting the mission of global, decentralized currency that Nano shares.

When a voting node, otherwise known as a Representative in Nano's terminology, gets 0.1% of the network's online vote weight delegated to it by account holders, it then takes place in consensus on the network. It gets upgraded from a Representative to a Principal Representative.

Running a Principal Representative is a great way for a social network to advertise commitment to the ideals of a truly global currency. Nano is such a currency, open and usable to all.

On NanoCharts 📊 you can view the current list of Principal Representatives voting to confirm transactions on the Nano network.

Lists such as this are a great way for large services (like social networks), merchants, etc... to show that they are strong supporters of Nano's mission through contributing to its decentralization. Wonderful for positive brand awareness 👍

That concludes this article on how Nano digital money could be integrated into a large social network. Hope you enjoyed reading and please consider sharing!