‘Someone’.

Hi, I’m Greg.

(this is how I usually introduce myself, although it sounds much better in my native Polish).

I’m currently the CTO@Userfeeds, where I’m responsible for creating technology based on our vision for new ways of information discovery. I’m really proud of what the Userfeeds team have managed to build in the short time since we launched. Each and every one of them has worked incredibly hard to accomplish feats we never thought possible, building technologies that created use cases for tokens that didn’t even exist at the time. I’m proud of them all.

Based on our initial technology, we managed to build two products; https://linkexchange.io and https://cryptopurr.co. Looking ahead, we see a future in expanding the cryptopurr.co concept, and spinning out a new product based on that idea.

Even though Userfeeds as an organization is to close, the project and the technology will continue to live and evolve.

We want to continue our journey into the uncharted territory of information discovery and social media for token holders. To give people the tools they need to navigate the vast sea of projects, tokens and information. Tools which will arm them against misinformation and exploitation.

Mission: Create a gateway to crypto-space for existing and new crypto users.

We will be creating a new organization to take over cryptopurr.co. With time, the project will evolve into a gateway to crypto-space for all token-holders.

Mission Objective: Exploration

People holding tokens often have no idea where and how they can use them. We want to provide a single location where people can share and discover information about crypto tokens and what they can really do with them.

We will also explore the implications of decentralized ownership, and look for new use cases which leverage ownership of tokens rather than trading.

Mission Objective: Expand understanding

We want to educate token holders about the potential of owning certain crypto assets, and what power this ownership can give to their voices on the Internet.

Mission Objective: Verifiable Information

‘Why am I seeing what I see?’ is, to us, the most important question right now on the Internet.

Why are you shown particular information? Did someone pay the interface to show it to you? Is someone trying to exploit you? Who are the people pushing this agenda? Are other people also seeing this information? How valuable is my attention to others? Is it undervalued?

All these questions can be answered with transparent and open interfaces, which can deliver the specific transactions and signed messages that were used to compose your news feed. You can see who wants your attention, and how much he is willing to pay for it.

Mission Objective: Increase Adoption

By providing non-monetary use cases of ownership, we want to encourage non-crypto users to explore crypto-space and adopt the common tools (like wallets) to interact with other users. Without any cost on their or our side.

Thanks to the unique nature of our ‘multi-chain’ products, we can provide users with the same experience regardless if they use real tokens or only test tokens.

Mission Objective: Interface Monetization

We will be providing monetization schemes for all users involved with our products. They will be able to assume the roles of content curators, and then monetize their insight, or as Influencers who can monetize by creating their own tokens. We also support Creators, who can design interface customizations, tying them to a given token and monetizing their work through token cloning/sharing.

Of course, users can have any combination of these roles to maximise their revenue streams.

We’ve implemented a ‘Hello World’ (simplest possible) monetization on cryptopurr.co. Anyone can deposit a small amount of ETH and then place their kitty on the front page (or any other profile page) of cryptopurr.co. This increases the chance of their kitty being noticed by other kitty holders or interested people.

Mission Objective: Shared Economy

Sender, Receiver, Contract and Interface: these are the four basic roles required to create an economy on the blockchain.

Each Sender wants to change the state of the smart contract (eg. he want to buy tokens), but he is not using it ‘directly’. He only discovered that this contract exists through an Interface, and he uses this interface to create a transaction to change the state of the contract. The Receiver is a gatekeeper for the contract, and only he controls the circumstances under which the contract can change (eg. he owns tokens). The last piece of the puzzle is the Contract developer who created the object that the Sender and Receiver want to control, but since contracts are inherently hard to interact with, they need an interface so that people can use them easily. By creating economies that encourage building new interfaces for existing contracts, we will be able to drive innovations in this area.

We want to convince developers to build contracts in a way that any developer can benefit from building new interfaces for a given contract, thereby increasing its usage and interface variety.

Mission Objective: Information Discovery

By combining economic information (blockchains) with purely social information (shared URLs, texts) we want to explore new ways of filtering and sorting social information. This will allow people to create their own filters based on their ownership of tokens and other assets. Creating a membership token and distributing it to your friends is just one of various ways to create new information-sharing circles based on crypto ownership. Even basic purchases can be interpreted as product recommendations when viewed from a certain angle. You can find new people based on their economic behaviors (Did he sell during the peak? Did he hold during the dip? Are his transactions reflecting what he is saying?).

Mission Objective: Collaboration

This is one of our most ambitious aims. We want other developers to help us build these products and be part of the economy. This will require considerable effort. Working with other people is never easy, but we’re prepared to do whatever it takes to help and be as open as possible toward new ideas and initiatives.

Mission CEO: Greg

I’ll be the CEO in this new organization. This is something I haven’t done before and I have much to learn. I am well aware of the difficult journey ahead. But beyond that challenge, I truly feel that we are at the beginning of something great. The beginning of a movement that will change the shape of the world, and I want to be a part of it, together with all the fantastic people I’ve met so far, and all the people I will meet along the way.

I’m counting on you all to keep me pointing in the right direction if I ever lose sight of the path.

We will build this future together.

P.S.

While we shift direction to a product oriented company, we need to ensure that the technology and services provided to our partners continues to exist. We are extracting the technical aspects of Userfeeds and maintaining our existing APIs and services for current customers.

P.P.S

We can’t do this on our own. We are looking for investors who are able to support a team of absolutely dedicated, insanely intelligent and exceptionally creative people.

P.P.P.S.

Healthy food is good for productivity. So is exercise, lots of exercise; go for a walk if you can, and get a lot of sleep.

G.

Part II: New beginnings was originally published in userfeeds on Medium, where people are continuing the conversation by highlighting and responding to this story.

This has been an incredibly hard decision for many reasons, so let me provide some context.

At the start of 2017 we raised the initial funding for Userfeeds. We predicted that the blockchain-based Web 3.0 stack would need a platform for ranking and discovering information based on crypto-economic relationships rather than links or likes. The Web would need something like Google PageRank, but for blockchains and tokens.

What happened next is probably true for many startups, but as a when you’re starting your first business you only realize these things with hindsight. We were able to build some really cool technology and hire a great team, but we failed to generate enough traction to secure the next round of funding.

Even though we’ve seen some promising results with the products built on Userfeeds tech, such as LinkExchange.io (AdSense For Tokens) and Cryptopurr.co (social feeds for Non-Fungible tokens), there just wasn’t enough excitement around them. Pivoting between platform-first and product-first approaches didn’t help the company either, as it diluted the core messaging and value proposition.

Running a startup is an emotional rollercoaster; one you can only really understand when you’ve ridden it yourself. In my case it was a rough ride, and the difficulties on the professional side very quickly became a personal struggle.

Given the circumstances and after talking to investors, it became clear that the best way forward is for me to step down. This will give both myself and Userfeeds time to reflect, recover and recharge.

As I step back, our co-founder Greg Kapkowski steps up. Greg wants to continue the vision we shared, and he’ll soon be launching a new company to take over the existing Userfeeds technology and develop it further. I fully support Greg in his mission to continue the project. You can read more about Greg’s vision for the Userfeeds successor here.

I’d like to take the opportunity to express my gratitude to our investors — Ciaran O’Leary and Philipp Banhardt from BlueYard (our lead investor) and Fred Ehrsam and Piotr Smolen who joined as angels. They have been extremely supportive throughout our journey, and if you’re an entrepreneur in the blockchain space looking for funding then these are the guys to talk to.

Finally, thanks to the team members who joined us on this expedition. I’m grateful for the opportunity and experience of working with you, and I’m looking forward to seeing what you build in your next big adventure.

Part I: The End Of The Journey. was originally published in userfeeds on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here you can read more about Cryptopurr and why sticking to mainnet is not always the best idea.

Why airdrop KETH?

We needed a way to get users on board with our Cryptopurr platform, and the best way to do that was to remove any potential barriers of entry. Since the biggest barrier for any dApp is the cost per interaction (whether it’s a post, a vote or a like), the most impactful solution was to hand out some free cryptocurrency. This has the added bonus of making the Cryptopurr user experience as seamless as possible.

Of course, if a user urgently needed to make their kitty purr with our app, they could request some test ethereum from one of the faucets (kovan gitter faucet). But we had a better idea. We could send Kovan ethereum (KETH) to all Cryptokitties owners so that anyone could write a message immediately, without the hassle of requesting it themselves. From the list of available test networks, we chose Kovan because of its speed. This proof-of-authority testnet has consistent speeds of one block per 4 seconds, so it was the perfect choice for a platform based on rapid interactions, which social networks are.

Cryptokitties owners list

At Userfeeds we deliver an aggregated API over ethereum blockchains. Among other things, we aggregate all ERC721 token transfers. Thanks to this, it was easy to retrieve all 72,000 addresses that owned at least one kitty. You can see a list of owners for yourself directly in json format here. You can check out the API yourself if you want to generate your own custom group of recipients.

Massive amount of KETH

Let’s start with a rough approximation of how much KETH we need for a targeted airdrop of this size. We want to provide KETH to 72,000 addresses, and we want to let each address post a lot; let’s say 100 times. Hopefully 100 user interactions will be more than enough for Cryptokitties owners to see the fun of the Cryptopurr platform, and then they can retrieve more KETH from a faucet of their choice. Since each message on Kovan can be sent with 1 gwei gas price, we get a cost per message of less than 0.0001 KETH, leading to a grand total of 720 KETH for the whole airdrop. This might not seem like much, but one does not simply walk into a faucet full of KETH. Fortunately for us, Parity was awesome enough to give us all the KETH we needed, so kudos to them.

How to send 72,000 transfers

All of us have been hit by a massive gas bill at least once, and for our airdrop the bill was potentially enormous. A simple transfer of ethereum costs 21,000 gas. Multiply that by our planned 72,000 transfers, and the total cost is a massive 1,512,000,000 gas. This exceeds the gas limit per block on kovan (8M) nearly 189 times over, so we have to break it down into batches. We also want all transactions to be easily connectable with our airdrop event, which is why we decided to create a contract. Besides transferring KETH, the contract also creates an event on a blockchain (check out our github on that). It all ran perfectly, and you can see the results of our airdrop on etherscan, consisting of 360 transactions in all. To send them we used our own small tool, which you can check out on github if you want to be equally generous to your own user base. We initially thought about using metamask, but that only supports up to 20 transactions (because obviously, who would ever need more than that?) and our needs were a little more demanding. To get around this, we switched to a Parity client, and by adding a--warp flag we were able to sync to Kovan in less than 5 minutes. Using the --unlock flag also meant that we didn’t have to approve all 360 transactions individually, so the whole airdrop only took 51 minutes to execute from its initial run.

New owners

Sending KETH to all current Cryptokitties owners is great to get people purring, but it doesn’t help to expand the number of active users. And if you haven’t got your own kitty yet, don’t panic. We’ve also built a service that monitors the ethereum blockchain for new Cryptokitties owners, and automatically sends a fixed amount of KETH to their address. That way, new users can start purring on our platform as soon as they get their kitty. We use our public API to manage it all, so if you want to play around with it yourself, you can find all the documentation here, plus an example from the Kotlin code here.

Token targeted airdrop was originally published in userfeeds on Medium, where people are continuing the conversation by highlighting and responding to this story.

In previous posts we’ve explained why “Facebook for cats” makes sense, we celebrated the launch of Cryptopurr’s MVP, and we’ve also shown you how to fork our work to your own preferred ERC721 token.

Now we want to show you few examples of what you can potentially build with it.

① Custom rankings for in-game assets

Too many items make the list hard to read? Do you know the perfect sauce for matching cats? Add a social layer on top and review the services provided by the siring kitties.

② Broadcast & socialize the blockchain events

Have you seen this ethmoji wearing it? Is this celebrity cat having a kittens? Are you holding an Ethereum for last two years?

③ Reddit for ETH Fanatics

Verify the incentives of the author. Combining HODL Algorithm (Ethereum Held over Time) with user’s social reactions could result in ‘Skin-in-the-game’ Reddit.

④ Feed with featured posts

Create a Facebook-like newsfeed and monetize it with featured posts aligned with your users’ incentives, paid for by any ERC20 token.

Feed can be embedded anywhere!

PS We also have a Chrome extension coming up.

⑤ Decentralized Advertisement Networks

Use your cat to connect advertisers and publishers. Rank them by the amount of tokens received (this is LinkExchange.io algorithm).

∞ Personal Kittie

Receive crafted recommendations, just for you — happening on the open marketplace of personalization algorithms. This one’s in few years ^.^

How is this possible?

The Userfeeds platform is based on claims. Each claim is a small piece of metadata that’s injected into a blockchain transaction, which is then used to create a new relationship between the blockchain address and some arbitrary information. Once the transaction is signed by a user’s private key, we know the sender, receiver and the content of a message. It’s a bit like pointing your finger at a thing and saying it’s yours.

Claims are used to influence perceptions of others by linking consensual data with non-consensual claims about the data.

Once we’ve established a connection, we know everything about the behaviour of the address (since it’s operating on a public blockchain) and its correlation to other claims. Therefore the interpretation can be both non-consensual (subjective, social) and consensual (objective).

How to deal with all this data?

So what are we going to do with all this data? How is it even possible to read it all? First of all, we need to rank it. Ranked data is a feed that you see everyday: Twitter’s newsfeed, Google’s page, Spotify playlist recommendations, Yelp’s best nearby restaurants and so on.

Different sets of applications can be built in a spectrum of these messages, utilising different ranking methods. You can also integrate it with your existing Ethereum dApp.

Some of the rankings will prioritise more consensual information…

…showing price, genes match and kids success — all of this information is comprised of consensual events.

Some events are less consensual…

…such as interests.

As time goes by and your character develops a broader data set, the information displayed with probably become even more subjectified.

Any action performed on any interface can influence the ranking of all the other interfaces in a different way. That’s an important shift, as the owner of the data layer no longer controls the perception of the data. You don’t add a link to Facebook. The data stays on an open data layer, it can be interpreted in many different ways.

Is it only for ERC721?

Nope, you can also use the address itself or even the Ethereum Name Service.

How can I contribute?

We’d love to hear back from you and discuss how we can work together.

• developers — join our freshly created Gitter to discuss possible integrations of ‘feeds for NFTs’ with your dApp.
• NFT token owners and enthusiasts — if you’re not a developer but you’re still interested in NFTs, you can join our new Telegram group to discuss how to grow the value of your NFT avatars by producing and curating information.

Alternatively, you can always email us at developers[AT]userfeeds.io

Giving Cryptokitties thousands of social media platforms was originally published in userfeeds on Medium, where people are continuing the conversation by highlighting and responding to this story.

In a previous post we discussed a variety of potential uses for a social layer built on top of ERC-721 tokens, and explored how a platform like this might work. This post takes the form of a short tutorial which will show you how to build a social platform for an existing ERC-721 token. To keep things simple, we’re going to build a basic version of cryptopurr. Making sure we’ve covered all the bases, the first chapter also describes how to build your own ERC-721 token, if you don’t already have one. Next we’ll try to figure out how to attach unique avatars to our token. If you know how to do this, or you’re planning to add a social layer to a pre-existing token, then you can skip this section.

Building your own ERC-721 token

To make our life easier, we’re going to use Truffle. If you’re not familiar with Truffle, take a look at the documentation to get yourself up to speed.

To get started, install Truffle:

$ npm install -g truffle

Now let’s create a project. For this tutorial I’m going to use a RoboHashToken, so I’ve named the project’s directory ‘robohash’.

$ mkdir robohash && cd robohash

$ truffle init

$ npm init #confirm all default values

Since the complete standard of ERC-721 isn’t what you’d call small, we’re going to use an implementation of the ERC-721 token standard from the zeppelin-solidity library. To do that, we need to add zeppelin-solidity to our dependencies:

$ npm install zeppelin-solidity --save-dev

Once we have zeppelin, we can create our contract:

$ touch contracts/RoboHashToken.sol

To maintain compatibility with truffle’s development pipeline, we also need to create a migration file:

$ touch migrations/2_deploy_contracts.js

and fill it as follows:

var RoboHashToken = artifacts.require("RoboHashToken");

module.exports = function(deployer) {
 deployer.deploy(RoboHashToken); 
};

For more info about truffle migrations, take a look at the Truffle documentation.

Back to the contract. First let’s inherit from ERC-721Token

pragma solidity ^0.4.21;

import 'zeppelin-solidity/contracts/token/ERC721/ERC721Token.sol';

contract RoboHashToken is ERC721Token("RoboHashToken", "RHT") {
 ...

The two arguments of the base class constructor are the token’s name and token’s symbol respectively. Next we have to figure out how these tokens will be issued. Because I want to make it as simple as possible, I’ll create my token in a way that allows anybody to create their own unique instance of this token:

contract RoboHashToken is ERC721Token("RoboHashToken", "RHT") {
 
 function create() public {
  uint256 tokenId = allTokens.length + 1;
  _mint(msg.sender, tokenId);
 }

As you can see in the code snippet, all we need to do is invoke the internal function _mint which takes care of the whole creation process for us. Congratulations! You’ve just implemented your own ERC-721 token!

But let’s face it, the token itself isn’t particularly interesting. Fortunately, it doesn’t take much more work to turn it into a naming service. Thanks to this, users of your service will be able to claim their names, identifiers, emails etc. All we need to do is to allow users to pass their identifiers to the create function and store them into some kind of mapping.

contract RoboHashToken is ERC721Token("RoboHashToken", "RHT") {
 
 mapping(uint256 => string) internal tokenIdToName;
 mapping(string => uint256) internal nameToTokenId;

 function create(string name) public {
  require(nameToTokenId[name] == 0);
  uint256 tokenId = allTokens.length + 1;
  _mint(msg.sender, tokenId);
  tokenIdToName[tokenId] = name;
  nameToTokenId[name] = tokenId;
 }

 function getTokenName(uint256 tokenId) view public returns (string){
  return tokenIdToName[tokenId];
 }

 function getTokenId(string name) view public returns (uint) {
  return nameToTokenId[name];
 }

I’ve also created a reversed mapping, so it’s be easy to check the identifier of a particular tokenId.

Token’s avatar

Tokens are kind of abstract, so it’s much more satisfying for your users if your token can be visualized. Cryptokitties tokens are represented by their png/svg images, which are served from a backend, and the same story goes for pretty much all collectibles; the underlying token is represented by a remotely-served graphic. Following that theme, we’ll use the https://robohash.org/ website to generate images from strings. We’ll be simply concatenating “http://robohash.org/” with token’s name and “.png” postfix to create an url for each token’s image which can be later displayed on our interface.

Ok, so let’s summarize what we have by now.

Every user can establish a unique identity, which is implemented as a non-fungible token, and see a visual representation of their character based on the assets from http://robohash.org. Isn’t that great?

You can check the full source code here.

If you want to see how I wrote tests for this contract, you can check that out here.

Deploying a contract

Deploying contracts with Truffle is easy; all we need to do is to configure our network of destination.

To access the Ethereum network, let’s use Infura.

Because deploying contracts costs some amount of Ether, we need to grant Truffle access to our wallet. To prevent leaking our private key into the source code, I’m going to use a dotenv module.

So let’s get started by installing all of the modules needed to deploy to Infura.

$ npm install --save-dev dotenv truffle-wallet-provider ethereumjs-wallet

Now edit truffle.js and add the following:

require('dotenv').config({path: '.env.local'});
const Web3 = require("web3");
const web3 = new Web3();

const WalletProvider = require("truffle-wallet-provider");
const Wallet = require('ethereumjs-wallet');

module.exports = {
 networks: {
  ropsten: {
      provider: function(){
       var ropstenPrivateKey = new Buffer(process.env["ROPSTEN_PRIVATE_KEY"], "hex")
    var ropstenWallet = Wallet.fromPrivateKey(ropstenPrivateKey);
       return new WalletProvider(ropstenWallet, "https://ropsten.infura.io/");
      },
      gas: 4600000,
        gasPrice: web3.toWei("20", "gwei"),
      network_id: '3',
  }
 }
};

Next open up your .env.local and paste in your private key like so:

ROPSTEN_PRIVATE_KEY="123YourPrivateKeyHere"

Don’t forget to add .env.local to your .gitignore!

Various ethereum test networks are available for you to use when testing your contracts, such as Kovan or Rinkeby. I chose Ropsten for this tutorial because Ropsten ETH is the easiest to get at the moment. All networks are fairly similar and you can use whichever testnet you like, but for the remainder of the tutorial I’ll assume you’re using Ropsten just for convenience.

Visit https://faucet.metamask.io/ to request some test ETH. Once you’ve got some ETH from the faucet, you should be ready to deploy!

Once you are ready to deploy you can execute:

$ truffle deploy --network ropsten

Copy and paste the relevant address from the output into the Ropsten Etherscan search box and you should see your newly deployed contract!

For more info about Truffle networks configuration, click here.

If you want to claim your token, you can go to https://remix.ethereum.org/. Remove all the existing code, and paste in the following snippet:

pragma solidity ^0.4.21;

contract RoboHashToken  {
    function create(string name) public; 
}

Having a contract interface is the only requirement to be able to call its methods. Once you have that, switch to the “Run” tab on the right side of the Remix screen. Paste your contract address in the appropriate field and click “At address”. This generates a create method which takes one parameter. If you call it and everything passes successfully, you’ll have become the owner of your own unique ERC-721 token instance.

Building a social layer

Rather than build a complete website from scratch, let’s use an existing one: https://userfeeds.github.io/cryptopurr/. I’m not going to explain all the inner workings of this website in detail. Instead, I’ll focus on the changes we need to make to support our robohashTokens.

First let’s clone cryptopurr to a new directory:

$ git clone git@github.com:Userfeeds/cryptopurr.git
$ cd cryptopurr
$ git reset --hard 0626acd6bb7ce87bcd72cca4d8f1049241e8c0e6

We’re particularly interested in the following files:

1. .env — File with all the necessary environment variables to get the app working.
2. package.json — Standard create-react-app package.json file with all the application dependencies and scripts.
3. src/entityApi.js — Defines how the details about particular token are fetched from network and displayed on website.
4. public/index.html — Here we need to set the title of the html page.

Ad 1. .env

Set the following properties:

• REACT_APP_NAME — Your app name (in my case RoboHash).
• REACT_APP_INTERFACE_VALUE — Url where your website will be hosted.
• REACT_APP_ERC_721_NETWORK — Name of the network where your ERC-721 contract is deployed. Please note that even that your contract is deployed on particular network users will be able to create messages also on other networks (The power of the cross-chain!!).
• REACT_APP_ERC_721_ADDRESS — Address of your ERC721 contract.
• REACT_APP_BASENAME — Base url (in my case /robohash-book/)

Ad 2. package.json

• Change name and home_page and insert the same values here as you did in the previous file.

Ad 3. src/entityApi.js

The main thing we need to change here is the getEntityData function. This function fetches details about a particular entity from the backend. It takes tokenId as a parameter and returns a custom object which is then used to display our entity on the page. Since we don’t have our own backend, we’ll have to connect it to our contract on the ethereum network instead. Luckily for us,Infura can take care of this too.

We’ll use web3js to talk to Infura, but to invoke methods on our contract we also need its ABI (Application Binary Interface). We can obtain it from the robohash-token project by invoking the following command:

$ truffle compile \
  && cat build/contracts/RoboHashToken.json | jq ‘.abi’ | xclip

Next, paste it into the robohash-book project:

$ mkdir src/abi && xclip -o src/abi/RoboHashToken.json

Once you have your contract’s ABI, you can use it together with the contract’s address to create an instance of your javascript contract’s representation.

import Web3 from 'web3';
const roboHashTokenArtifacts = require('./abi/RoboHashToken.json');

const web3 = new Web3(new Web3.providers.HttpProvider('https://ropsten.infura.io/));
const contractInstance = new web3.eth.Contract(roboHashTokenArtifacts.abi, '0xfa9d471300b0a4cc40ad4dfa5846864973520f45');

At this point we should be able to call the contract’s methods, so let’s implement the getEntityData function.

We will invoke getTokenName with entityId to obtain the name of that token, and then use getTokenUrl to get the robohash image of our token.

export const getEntityData = async entityId => {
  try {
    const responseTokenName = await contractInstance.methods.getTokenName(entityId).call();
    const tokenName = responseTokenName.valueOf();
    const responseTokenUrl = await contractInstance.methods.getTokenUrl(tokenName).call();
    const tokenUrl = responseTokenUrl.valueOf();
    return {
      id: entityId,
      name: tokenName,
      image_url: tokenUrl, // image of our entity
      url: `https://robohash.org`, // website with details about particular entity
      color: '#333333' // background color 
    };
  } catch (e) {
    console.error(e);
    return undefined;
  }
};

Next we have entityTranslations which defines the texts displayed across the application. You can change them to suit your website theme and local language. I defined them as follows:

export const entityTranslations = {
  commentPlaceholder: 'Hash your story',
  replyPlaceholder: 'Hash your reply',
  noEntitiesError: 'No robohashes found',
  entityName: 'RoboHash'
};

The colors map from line 4 defines the appropriate background color behind the kitty. Since we will have only one background color across the site, you can remove this entirely.

Finally, we need to adjust avatarSizes. The best approach to do this is to open our application, find the right values using the web browser console, and then write them into the file. Once all of that’s taken care of, your application is finally ready to launch.

To start the application:

$ yarn
$ yarn start

For me the correct values for avatarSizes were as follow:

export const avatarSizes = {
  verySmall: { containerSize: '32px', imgSize: '32px', imgTopOffset: '50%', imgLeftOffset: '50%' },
  small: { containerSize: '44px', imgSize: '44px', imgTopOffset: '50%', imgLeftOffset: '50%' },
  medium: { containerSize: '54px', imgSize: '54px', imgTopOffset: '50%', imgLeftOffset: '50%' },
  large: { containerSize: '64px', imgSize: '64px', imgTopOffset: '50%', imgLeftOffset: '50%' }
};

Ad 4. public/index.html

• In the line 23 you can change the title.

Congratulations! You’ve built your own social platform for your collectibles! Because the application only consists of frontend (the backend is taken care of by the ethereum network), you can even deploy it using github pages!

That wraps up this tutorial. I hope that you enjoyed reading, and if you want to duplicate it for yourself, all the code can be found in the following repositories:

• https://github.com/Userfeeds/robohash-book
• https://github.com/Userfeeds/robohash-token

If you look closely at the https://github.com/Userfeeds/robohash-book repository, you’ll find some additional commits. They show how we adjusted the code to add the option of issuing new tokens directly from our interface, plus how we configured Truffle to deploy to mainnet. And remember, even if your contract was deployed to mainnet, your users don’t have to write messages on the same network. Thanks to the Userfeeds platform they can also post on other test networks such as Kovan, where Ether is free! If you are interested how this whole solution works under the hood, stay tuned for the next article which is coming soon.

Let them speak — A simple guide on how to build a social platform for an ERC-721 token was originally published in userfeeds on Medium, where people are continuing the conversation by highlighting and responding to this story.

Purr something!

We just officially launched our first iteration of “Facebook for cats”, explained in this post. To celebrate, we’ve decided to give each of our followers some Kovan Ethereum to help you start purring. Even though your cat belongs to mainnet, you can use this Kovan Ethereum (or any other test net) to purr for free, without bloating the network.

Cpt. Barbossa sent 800 kETH to ~70000 addresses that own at least one kittie.

If you don’t have a cat, perhaps you own an Ethmoji or Cryptobot instead, or want to create your own Robohash? No problem: this method, and the free Ethereum, works with these as well.

What can you do with that?

• Purr, obviously

• Purr to another kittie

• React

• Colonize existing web 2.0 channels

• Reply to messages

How to switch to a test net?

Log in to your MetaMask. In the top left corner, click ‘Main Network’ and in the displayed menu, select Kovan.

If you owned a kittie before the airdrop you should see balance of 0.1 Ethereum. You’re welcome!

Supported by Trust Wallet

You can purr on your mobile device! Just make sure you’ve chosen Kovan as the network.

Can I fork it?

Yes! Integrate it within your dapp, curate your own feed, prioritize particular cats or do anything you can think of. Message us!

How did you send an airdrop with the message?

It’s easier than you think! We’re working on a tutorial for you.

What else can I build with it?

Basically anything that utilizes rankings, messages and reactions (Facebook, Reddit, Twitter, Spotify, Yelp and so on).

How can I contribute?

We’d love to hear back from you and discuss how we can work together.

• developers — join our freshly created Gitter to discuss possible integrations of ‘feeds for NFTs’ with your dApp.
• NFT token owners and enthusiasts — if you’re not a developer but you’re still interested in NFTs, you can join our new Telegram group to discuss how to grow the value of your NFT avatars by producing and curating information.

Alternatively, you can always email us at developers[AT]userfeeds.io

Special thank you to blockchaingamer.net for supporting us!

Do you own a cryptokittie? Have some kETH! was originally published in userfeeds on Medium, where people are continuing the conversation by highlighting and responding to this story.

Data Layers

First, I want to introduce you to my concept of data layer. The term is used to describe many different things in architectures of products and software systems, that’s why I want to explain my definition of data layer.

If we started to examine many existing systems they could be described with this diagram:

At the bottom of the diagram there is a rectangle titled Database. It usually means: data structured in a specific way enabling their processing and a processing software that is able to access the data and do something with them.

This combination of data, structure and software (being able to operate on the data with given structure) is my definition of Data Layer. One without the other cannot work to deliver value. You need all of those components working together.

Data Layer: Structured data and processing software that is able to operate on the structure.

An example of data layer is of course your database cluster, or single sqlite.db file sitting somewhere on your server and application modules reading the file or even API sitting on your server and waiting for valid request to fulfill.

Walled gardens

All of mentioned examples of Data Layers have something in common. They don’t want to share all the data and processing capability with outside world. But only with selected few who have proper credentials.

The biggest value gathered by companies on their servers is the data. Every day millions of records about people/things/places are gathered, retrieved and processed. All stored and carefully guarded.

That’s why current database systems come with built in authorization and security mechanisms, limiting the access to only those individuals who are able to prove they have the right to see the data.

This creates a world where innovation, that could be created based on those data, is limited to platforms gathering them. You cannot get all the data from Twitter, Facebook, Google, Amazon or any other platforms, even the small ones.

That’s because business models of those platforms are based on data gathered by them. The data is their economic advantage.

But what if we change the business models of those companies?

I’m specially thinking about Tokens, and ICOs that started appearing some time ago and right now look like there is no stopping to them. (Yes there is a lot of scam there, but that’s a topic for different article)

What if we could create companies providing similar functionalities to existing platforms, but relying on tokens as their business model? I don’t want to propose any specific model because that might vary between companies. I’m assuming a model where the biggest advantage is given not by the data but by number of people holding/trading this company token(s).

Given those companies/projects and their new business models, it could become beneficial to those companies/projects to share the data they are gathering. If some other project would start using their data it would make their token more desirable.

(That’s what we are planning for Userfeeds Platform, all the data that we gather will be available for external developers/projects to use and experiment with, and we will be focusing on adding more and more data sources as blockchain space grows and matures. You can read about the data we are gathering here)

Now, that the stage is set, let’s jump into main topic of this article

Open Data Layers

The idea of Open Data Layers is to provide identical data and processing capabilities, to everyone interested in the data, as you have inside your platform. Much like how blockchain works, or rather its peer-to-peer synchronization part.

Open Data Layer: Structured data and processing software that is able to download data and operate on the structure.

In blockchain world if I want a copy of given blockchain I need to download appropriate program and run it. That’s it.

I think Open Data Layers should work identically. If you are interested in some data you just download appropriate program (database server etc.) and run it with information which Open Data Layer should be the source. Without ever asking for permission or credentials.

(Not all data are appropriate for such sharing, especially those tied to your human identity, but in blockchain world we started identifying individuals by their cryptographic signatures (public/private key pairs) and information tied not to you directly but to one of you public keys (economic identities) tends to be more valuable when shared with everyone.)

The architectures of different applications using the same Open Data Layer could be pictured like this:

Technical perspective

For open data layers to start growing we need help from database projects. They would need to provide new mechanisms for reliable data sharing in ways similar to what they are currently doing for replication and reliability but with very different reason behind.

Current databases are very good at replicating data between nodes in a cluster (any production ready database system has such capabilities). But those mechanisms where built to share data only with limited audience. You might have capability to setup read only nodes and share them outside your cluster, but you need to know about those nodes.

With open data layers we need peer-to-peer solutions that would allow everyone to setup node for any data layer without asking for permission and with the same processing capabilities as the data source. Those additional nodes wouldn’t be able to modify data of original source, or their attempts to do so would be ignored, but it should not prevent the user from adding new data to his node outside of the data being replicated.

The basic architecture of system sharing its internal data could look like the diagram above. Where system nodes are internal to the data operator (they are the ones controlling/creating the data) and are allowed to alter the data, gateway nodes are designed to pass data from system nodes to external readonly nodes. Readonly nodes would then have capability to replicate from other readonly nodes or from gateways allowing for better load balancing.

Conclusion

Right now Open Data Layers is only an idea. We need companies whose business models encourage data sharing. If you are creating such company, let us know.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

We, at Userfeeds, are thinking of ways to efficiently share our data with everyone. We’ll be gathering people interested in data storing, processing and sharing to start this conversation. We are using Neo4j and PostgreSQL databases internally and this will be starting point in our journey towards Open Data Layers.

Open Data Layers was originally published in userfeeds on Medium, where people are continuing the conversation by highlighting and responding to this story.

(Not all data described bellow are already available. Systems to gather them are being actively developed.)

Lets start with most crucial data required by Userfeeds Platform to function properly.

Blockchain data

Blockchain data like accounts, token balances, token transfers etc are crucial for Userfeeds Platform ranking algorithms to function properly. Not only financial data are important but also what were behaviors of token holders, do they hold token for really long time or are they trading constantly with different tokens, all this information can be taken into account while calculating rankings.

Example of graph representing accounts and token transfers:

Blockchain information hold in Userfeeds Platform databases are:

Accounts (Economic Identities)

Accounts (or rather Public Keys), are treated as identifiers for so called Economic Identities — Identities that manage some economic value.

Userfeeds Database contains all accounts used in any transaction ever made on Etherum Blockchain (currently only Ethereum as we decided to start with it and expand later)

Account Balances

Except accounts, we gather asset (ETH & ERC20) balance data for each account after each block. So you will be able to look at the data from perspective of given block.

Asset (ETH & ERC20) Transfers

Along with Accounts we gather information on all transfers of ETH and ERC20 compliant tokens, we are not differentiating between those two as from our perspective transferring ETH or ERC20 token i a transfer of value between two parties, and this is crucial information to us.

(Again, we are gathering data from Ethereum blockchain first but the data structure inside our Databse is source/blockchain agnostic.)

Aggregated Data

We provide some basic aggregated data that are used with our built in algorithms.

Hold — Aggregated holding of given token over time

Claims

Second most important data gathered in Userfeeds Database are Claims. They are glue connecting Economic Identities from blockchain with content present on the Internet (or anywhere else assuming content have proper identification method).

Claim is digital equivalent of pointing a finger at something. This requires for this something to have proper identifier that can be references in claim. For example URLs are quite nice identifiers, https://userfeeds.io/ leads directly to current version of Userfeeds home page and assuming there will be no attacks or configuration issues it will lead there for quite some time. But URLs are not ideal that’s why claims don’t assume anything about their target, you could use IPFS hashes or magnet links or anything that you know how to resolve into content. No all identifiers need to make sense to everyone in order for one to use Userfeeds Platform. You could agree with couple of other people to use your secret resolver and still be able to use all functionality of Userfeeds Platform, you would only need to provide some Interface/App that would decode your identifiers into proper content.

Example Claim:

A more complex example of claim used in http://linkexchange.io/

And somewhat more complete graph representing two claims made by the same author:

Claims are the glue layer connecting blockchain information with content layers (like webpages). With this in place we can start looking at content layers (eg. youtube urls) from perspective of economic networks (token holders).

What can be done with the data?

Content ranking

Most basic functionality of Userfeeds Platform is to provide a way to run ranking algorithms on data gathered in Userfeeds Platform databases.

Most ranking algorithms intended use is to filter and sort content based on criteria passed to the algorithm.

One example of such algorithm would be to get all claims of type link and sort them according to sum of all token transfers (from one token) accompanying each claim. You could then display list of 5 links on your web page and earn tokens when people want to promote their links on your web page (this is a very simplistic explanation of how linkexchange.io works).

Another example of content ranking would be if you had you own token and a web page displaying images. Anyone with your token would be able to display images on this page but the order of images would be determined by how long and how much of your token those people hold.

Yet another idea would be to sort any links provided by holders of token X according to their token holdings. This could be displayed on web pages of mobile applications as news feed of information related to Token X.

Userfeed Platform already gathers this information and will provide algorithms that will allow those uses.

Economic Friends

Imagine that you could read news feed, much like you are doing on facebook, reddit or twitter but it would be generated not based on your social connections but economic ones.

Lets assume you are holding 5 kinds of tokens, Token A B C D and E. You hold 100A, 100B, 100C, 10D and 10E.

Now imagine an address that holds 120A, 100B and 80C. Your economic incentives are more or less aligned, but you don’t know this person. He/she/it might be using twitter/reddit/facebook but you have no way of knowing which accounts on those platforms are connected to this address (they could post their address on those platforms , but looking for this one entry is not so simple).

Would you be interested in reading information shared by this one person? Or aggregation of information shared by people holding similar tokens to yours? Or yourself sharing information to the people having similar token holdings?

Networks of tokens

Somewhat similar analysis of token holding as Economic Friends can be done with tokens themselves. By looking at addresses that hold token X and Y we can calculate what percent of them holds both tokens and how close those tokens are.

This information could be used to make recommendations of new tokens you might be interested in and their news feeds, or maybe the other way around, you could filter out from your news feed of token X all information from addresses holding token Y.

Userfeeds Platform: Data overview was originally published in userfeeds on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR: If you don’t want to read the article and just play with the demo widget just go to http://rinkeby.etherscan.io and click on the Ether icon in the sponsored link.Thanks to Etherscan for supporting our alpha! PS. Make sure to have Metamask installed with some Rinkeby test Ether to be able to bid on links.

At Userfeeds our mission is to help users allocate their attention more consciously and effectively in the increasingly noisy and competitive environments of the modern Web.

The core belief that underlies everything we do, is that the global economy is in the middle of a paradigm shift toward a new model where the most valuable scarcity is human attention. This shift has much more profound implications than most people recognise today and will transform the future of business models, governance, politics and even individual lifestyle choices.

Individuals and organisations that will most successfully navigate this transition are the ones who can understand this new economic reality earlier than others. And quickly adopt new mental models and technological tools to take advantage of new opportunities. The challenge that most will face is that our external economic environments and internal, “natural” biological impulses evolved to constantly satisfy a scarcity of information that no longer exists.

At Userfeeds, our goal is to:

1. explore and evaluate mental models and heuristics designed for the new economy of attention scarcity
2. build blockchain-based software platforms that help users allocate their attention using these heuristics

We look at blockchains as a communications technology that allows signaling of incentives between economic actors that have scarce attention to allocate. We think that in the nearest future, all attention allocation decisions (‘what I want to see and what I want to ignore’) will be based on the algorithms that use incentive alignment between sender and receiver as one of the key ranking signals.

Apps, Developer Platform and Research on Attention Economics

Since our funding announcement a couple months ago, we’ve been thinking a lot how to prioritize efforts given our resources, maturity of the blockchain technology and goals we want to achieve.

We made a decision to focus on 3 areas:

1. end user applications — LinkExchange which can be described as ‘Google AdSense For Tokens’ aimed at users, advertisers & publishers in the crypto space that we built on top of the Userfeeds Platform.
2. developer platform — Userfeeds Platform which is the platform for app developers that enables them to run signaling metaprotocols and ranking algorithms based on tokens. LinkExchange is the first product built on top of that platform.
3. research & conceptual work — theoretical work around attention economics that is foundational to both applications and the platform.

All three areas are on different levels of abstraction — with LinkExchange being the most concrete and practical and the research work being the most abstract and related to fundamentals of attention economics.
Compared to our initial plans, we decided to build the initial applications ourselves (like the LinkExchange) rather than target 3rd party developers from day one. It allows us to test the underlying platform and showcase the examples of what can be built.

We’re super excited about LinkExchange and think it might be a new way of monetisation for the online publishing industry and the method for reinventing incentives between users, publishers and advertisers.

In the meantime, we’ll be releasing more information on the technical and architectural choices behind Userfeeds Platform and papers on the underlying attention economics.

What is LinkExchange? — the elevator pitch

LinkExchange is like ‘Google AdSense for token-based communities with incentive-based targeting mechanism’.

LinkExchange offers publishers in the blockchain space a native method of monetisation by allowing them to display sponsored links on their websites in exchange for Ether or any ERC20 token.

For advertisers, the token they use to transact with the publisher has a dual use case:

• it’s a medium of exchange and unit of account — just like USD or EUR they’d use in traditional ad networks.
• but more importantly — it’s the incentive-based targeting mechanism.

In other words, advertisers use the token owned by the community they want to reach with their message. Token is a method of signaling their alignment with token holders and being more attention-worthy than the ‘outsiders’. Transparency and open nature of the blockchain allows users to audit every single ad that is competing for their attention.

Token-holders can always see who is bidding for their attention, what token they’ve used to buy the link and all other details they might be interested in. All transactions are recorded on the Ethereum blockchain and are fully transparent and auditable.

You can play with the demo widget today at: https://rinkeby.etherscan.io

It’s all about incentive (mis)alignment

Traditionally, advertisers used keyword, behavioural or demographic ad targeting methods.

While extremely effective, these methods require publishers or platforms to collect data about the users, in order to allow for more precise targeting. The more data about users they collect, the better targeting they can offer.

The challenge with this model is that interests of users, advertisers and publishers diverge quite quickly. Everyone is pulling in their own direction. Platforms have to silently collect more data into their private silos because that’s the only way to remain competitive. Users respond with ad-block limiting the amount of attention publishers can sell.
With incentive-based or token-based targeting, all three groups are incentivized to support each other by using the same token to exchange attention to capital.

For obvious reasons, this method can only work for a subset of advertisers who are interested in reaching holders of specific tokens. Also, the number of token-based communities is still small relatively to the number of communities on i.e. Facebook. But the hypothesis we want to verify soon is that for in the niche of token-based communities, LinkExchange can provide more value to all parties than Google AdSense or other 3rd party ad networks.

How It Works?

LinkExchange allows every Ethereum address to act as a decentralised advertising network. Just like with Google AdSense, the publisher configures the widget and embeds it on a website they control. Potential advertisers can pay to display ads in this widget.

The difference lies in how everything works under the hood.

In LinkExchange, the publisher specifies the Ethereum address that identifies the source data feed for the ads. We call that Ethereum address — a Userfeed address.

All links sent by advertisers to that Userfeed address are added to the data feed that will be ranked by the algorithm in the next steps.

Technical note: ‘Sending links to the Userfeeds address is done by our proxy contracts that forwards the money to the Ethereum address specified by the publisher and generates an event log with a link metadata (we call it a ‘claim’). The Userfeeds Platform then aggregates and parses the event logs using the algorithm selected by the publisher.

The algorithm can contain arbitrary ranking rules and its output is the ranking of the links.

To prevent spam and abuse the publisher can turn on the whitelisting option that allows them to moderate the ranking and only display links that were explicitly reviewed and accepted by them.

The publisher can additionally set how many top links from the ranking will be displayed in the widget. We call this number — a number of ‘slots’.

For example: there might be hundreds of whitelisted links but if the number of ‘slots’ is 10 then only 10 top links will have a chance of being displayed.

The links that are high enough in the ranking and make it to the slot are assigned a probability score which determines their probability of being displayed on the next impression of the widget.

Pay-per-Probability model

In the Pay-per-Probability model that is central to LinkExchange, the advertiser uses the token transfer to the address specified by the publisher to increase probability of their link being displayed in the widget on the next page view of publisher’s site.

The probability score is calculated using the algorithm specified by the publisher and the amount of tokens sent to an address is just one of the variables. The publisher might choose to use other variables such us as time, to modify the probability calculation to influence incentive structure in their link widget.

So depending on the widget’s expiration date (the publisher can declare how long they intend to maintain the widget) and expected traffic, the advertiser can place their bids.

But… does this mean more advertising that everyone hates?

On the surface LinkExchange widgets look just like the regular advertising widget so where’s the hype and do we really need more ads?. In reality, it’s like looking at the electric and internal combustion engine car.

They might look the same externally but their engineering, design, economics and business models are worlds apart.

The idea behind LinkExchange is to reimagine incentive structures behind ad placements that we’ve learned to hate so much. We use the same familiar UX of ad placements but feed them with data coming from the open data layer (the blockchain) with token-based economics.

The distinction between content and advertising becomes blurry and is dependent on the incentives of the reader.

Are you a crypto-publisher? Would you like to join the pilot?

We’re still polishing up the product but if you’re a publisher that serves token-hodling audiences and would like to pilot LinkExchange — please let us know (via the contact form at userfeeds.io or in the comments)

Introducing LinkExchange powered by Userfeeds was originally published in userfeeds on Medium, where people are continuing the conversation by highlighting and responding to this story.

In 2017, no one doubts anymore that the ‘age of algorithms’ has arrived. The economic and political power of content ranking algorithms was brought to the mainstream attention during the last presidential election in the US. Issues like ‘fake news’, the opacity of discovery algorithms and centralisation of advertising revenues among dominant platforms are now being publicly discussed even in the non-tech circles.

At Userfeeds, we look at these issues in the context of a wider systemic economic change that’s happening now in the digital world. With the exponential growth of information sources and free digital distribution, human attention became the scarcest and most desired asset of the online economy.

Aggregation and control of global attention flow are the #1 online businesses because wherever attention flows money follows. The multi-billion dollar valuations of companies such as Google or Facebook result from their ability to attract, package and sell attention for dollars.

Incentives Behind Algorithms Shape Our Reality

The abundance of choices forces us to rely on algorithms to determine what’s relevant and ‘true’. It’s inevitable that these algorithms will become even more important in shaping our perceptions in the coming years.

The issue is that economic incentives behind these algorithms are opaque and not well understood.

In our view, such diverse problems as ‘fake news’, spam filtering, ad targeting, ad-blocking, newsfeed censorship and moderation are essentially information ranking problems. But companies operating algorithms behind these rankings are not neutral and have their own economic goals and incentives they optimise for.

We Have To Bring ‘Skin In The Game’ back to the Attention Economy.

Competition for attention in the current environment has a strong asymmetry that favours platforms and content producers at the expense of the users.

What do we mean by that? We already pointed out that there’s a fixed supply of attention that everyone competes for. For us users, whatever we pay attention to has a cost — we won’t get that attention back. In addition to that, once we let information enter our minds it will stay there and affect our thoughts and future actions.

Even if we try to evaluate information and decide it’s untrustworthy or misleading it is still a mental cost we have to absorb. The only way to avoid that cost is not to see that information in the first place.

The ranking algorithm should optimise users attention and prevent them from seeing the misleading information.

The question is: what the algorithms optimise for?

Unfortunately, the current ecosystem has a built-in ‘principal-agent’ problem. Platforms and content producers benefit from showing you things and putting them into your mind. The attention you provide and the data trail you leave will immediately benefit Facebook and the content producer that got your attention through Facebook.

Your attention is immediately exchanged to dollars through advertising and the data you leave behind improves Facebook. But the costs of seeing bad quality information will be absorbed by you. Potential consequences of that exposure will often be hidden and delayed in time.

In a way, incentives of Facebook (and other media platforms) are similar to incentives of Coca-Cola. Coca-Cola generates cash from sugary water sales but has no downside of absorbing health costs from overconsumption of sugar. In fact, for many years the risks of sugar consumption were not recognised, and because they were delayed in time, it was hard to link them to sugary drinks.

As an early information society, we still don’t recognise dangers of letting other people with opposing incentives to put images and thoughts in our heads at no cost.

And in the current environment, producing toxic information that is viral is essentially a free option on attention. By free option, we mean a situation where information is free or almost free to produce but has a potential to generate lots of attention dollars if it spreads virally.

Everyone benefits apart from the ‘attention suppliers’. The platform gets the data. Content producers get eyeballs and traffic. Both of which are instantly monetized. Users, however, receive a short-term dopamine boost from consuming low-quality content (which is often designed to by emotionally engaging, confirm their previous beliefs, stimulate outrage) but don’t recognise the long-term opportunity costs associated with it.

The concept of ‘skin in the game’ as explained by Nassim Taleb means that if you can expose others to harm you also should be exposed to some of this harm yourself. It’s all about symmetry. If there’s no ‘skin in the game’ in the system, it will blow up at some point. Any system where one party keeps all the upside, and another absorbs the downside is doomed to fail.

The best recent example of that is the financial crisis of 2008, where the upside from risky instruments was kept by the bank managers, but losses were transferred to the public.

We think that the current economics of the online media landscape is set up in the similar fashion.

The upside from aggregating and trading attention is captured by a few players but the downsides and delayed risks from surfacing misleading content are externalised to the users.

Show me your tokens, and I’ll tell you what your beliefs are.

Cryptocurrency innovations like Bitcoin and Ethereum are not usually linked to online publishing and advertising but rather perceived as financial innovations.

But at their core, these technologies are built on ‘skin-in-the-game’ principles and symmetry in decentralised systems.

The entire concept of ‘mining’ in the world of cryptocurrency is nothing more than a mechanism proving that someone has sacrificed some economic good (in this case — electricity) to receive a reward from a network in the form of new coins. It’s ‘skin in the game’ rule applied to token allocation.

No one cares if you say you support Bitcoin. You prove your support with ‘proof-of-work’.

What if we applied the same idea to allocating human attention?

What if ‘attention seekers’ had to back information they promote with similar ‘proofs-of-sacrifice’ instead of easily gamed likes or votes?

What if we could bring symmetry to online relationships where every time someone wants your attention they’d have to prove what incentives they have, and they’ve had to sacrifice something to make you pay attention to them?

The concept of digital tokens on platforms like Ethereum, allows us to design systems where tokens can be used for signalling relevance of information to communities owning these tokens.

‘Tokenized’ Ranking Algorithms

At Userfeeds, we develop the engine that will support many ‘tokenized ranking algorithms’.

By incorporating token-based signals into information ranking algorithms, we can install ‘skin in the game’ filters for our attention.

Today, when you see an ad on the Web, you see it because somebody created a ranking signal by paying dollars to the advertising network which you probably don’t own.

Advertising platforms are essentially platforms for ranking algorithms that use dollars or euros as their primary ranking mechanism.

If you transfer dollars to me, I’ll boost your position in the search results — that’s the deal with the AdWords platform. Using this simple but powerful value proposition, Google makes its money.

How would the economics behind advertising change if owning a token would be a prerequisite for getting the attention of a targeted community?

Send Signals With Your Tokens.

Tokens are stored on the public ledger, visible and accessible for everyone. Token holders can already send ranking signals by signing arbitrary messages with keys corresponding to their token holding.

What we’re missing is the infrastructure that could interpret such signals, construct interaction graphs and apply algorithms on top of them to build discovery rankings.

Having such infrastructure would allow every community of token holders to allocate attention and discover content using signals coming from the inside of the network. In other words, the token would become a frame of reference for ranking information (and allocating attention) for its community.

Our first product, the Userfeeds Engine will allow everyone to generate rankings based on blockchain-based and off-chain signals.

It’s Not Only About How Many Tokens You Have

A common feedback we receive when describing the idea is that it leads to large token holders having more voice in the community.

It couldn’t be further from what we’re building. While it’s possible to create simple rankings based purely on token holdings we expect a whole range of other algorithms that will take other signals into account.

For example, due to the open nature of the blockchain, we can use signals such as duration of holding. You could create a ranking where long-term token holders, who proved commitment to the network receive boost in rankings. In other cases, recent activity of a token holder could be a key ranking factor. The algorithm design space is infinite here.

Another interesting use case could be a ‘proof-of-donation’ based ranking. Many websites display their BTC or ETH tipping addresses, but today there’s not much incentive for visitors to contribute tips. A simple application built on top of the Userfeeds Engine could allow donors to display messages on the website as a reward for a donation.

There are many other examples which we’ll explore in the future blog posts.

Why We’ve Chosen To Raise A Private Seed Round Instead of a Token Sale.

One might ask then, why did we decide to raise a private seed round instead of a public token sale if we are believers in a ‘tokenized’ digital economy.

Indeed, the token sale option was on the table, but we’ve realised that we still needed funds to build proper proof-of-concepts and fully explore the idea before running a token sale.

Fortunately, we’ve met investors who understand the space well and were excited about the problem to back us financially on our journey. We’re grateful to have them on board. Their support provides us with time and funding to make the vision more concrete before we open up to stakeholders from the community.

Once we’re confident with the early results, we will definitely explore the token sale option again.

Stay tuned!

Userfeeds got funded! Here’s how we plan to bring ‘skin in the game’ back to discovery algorithms. was originally published in userfeeds on Medium, where people are continuing the conversation by highlighting and responding to this story.