Friend-to-Friend Content Discovery & Community Feeds

With TrustWallet forced to remove their DApp list, we see the predicted shortcomings of the app store approach. I thought I’d take to time to re-tell an original feature of Status, since removed, which I guess is now called Oldschool Discover. It may be an interesting use-case of the upcoming data-sync layer.

‘Regulatory issues’ aside, the main issue I have with app store approach is that it always seems to be a variation of a ‘Sponsored Search Auction’.

By presenting the same list of items to all users you effectively create highly valuable screen real estate, and at the same time give yourself the responsibility of fairly allocating the scarce resource, hopefully to maximize welfare.

The more users the app-store has and the higher the click-through-rate of the top positions the higher the incentive to take those slots, if the cost of acquiring users is less than the return made, you have a problem.

In summary:

  • we’ve created a highly valuable scarce resource
  • we have to equitably allocate that resource
  • ultimately the top positions go to the highest bidders

We can fix this by creating a subjective system. By doing so we can democratize the screen real estate, and we can treat users themselves as ‘spam filters’ for content by their private use of the application.

That means that each user’s ‘app store’ is unique, no one sees exactly the same content. Some users may not even be aware of certain kinds of content. And for the user to get the content, their contacts have had to collectively ‘approve’ content in some form.

We do this by treating content as messages (henceforth known as statuses) in a gossip/epidemic protocol, where information is spread in a manner similar to the spread of a virus in a biological community.

The original idea was that a user published ‘statuses’, meaning that every ‘dapp’ would be attributed private account, which was to be used in conjunction with the automatically generated public chat based on a hostname (a feature that thankfully survived), to offer private support requests. Another interesting feature is that this is very much inline with 4th industrial revolution / gig economy trends.

The user has to publish their status to their contacts, and those contacts will publish to a set of statuses to their contacts based on a set of rules.

The set of rules acts as filtration of content, all are determined client-side. Some examples would be.

  • Payload size (the amount of statuses to transmit to contacts)
  • Frequency of publishing payload
  • Frequency of publishing status from same public key
  • Weight Payloads by age of contact in client
  • Weight statuses by publication date of status
  • Weight on if mutual contacts have transacted with each other
  • Contact uptime
  • Duration spent chatting with Contact
  • Duration spent browsing/chatting with status.
  • Contact that publishes a status a mutual contact?
  • Detect Duplicates Levenshtein distance of the status string versus others
  • Client word filters
  • Clients internal reputation score based on chains of signatures.
  • Whitelist/Blacklist public keys
  • Client user’s own spam reporting / downvote (maybe upvote)
  • Bloom filters of known ‘bad statuses’

For a status to successfully appear on the content discovery screen, it must successfully traverse through real-world usage to enter into the user’s payload and be transmitted to their contacts.

Essentially the fixed-limit payload becomes a k-Unit auction and the status bids are determined by the client’s ruleset.

Ultimately the effect is that communities of users will see different content. But statuses that provide real universal utility will continue to propagate and achieve network saturation. I suspect the costs for a nefarious publisher is substantially higher with penetration rates being lower.

statuses could be signed on each retransmission, allowing the client to see the propagation trails and keep reputation scores of unknown contacts, however this has some privacy issues.

I don’t have any suggestions for the UI, the original idea was to have a twitter-like feed that could be filtered and aggregated based on hashtags, as to show new statuses as well as have dynamic categories (another issue with app store approach)

Such a system would allow us to control the onboarding content for a user (by being a default contact in Status) ie a support contact or me as Tom like in MySpace, allowing us to populate and comply with regulatory concerns, that the user can also opt-out of by removing the contact.


Thinking of what this might look like on the UI side. Is Spotify’s ‘Friend activity’ a reasonable example of twitter-like feed? Only instead of friends you might see public channels associated with a given DApp and the order is based on a collection of statuses that differs for a user based on topics they are subscribed to.

This part is a bit mindboggling for me. Please correct my understanding below:

  • Alice uses a DApp
  • Alice client publishes statuses of use (based on rules)
  • This use is associated with the DApp private account
  • The statuses are published by Alice client, but are a report on the DApp only associated with the DApp, not with Alice

It feels a little like a virtual “I was here” graffiti tag. Where Alice publishes a tag for everyone that contains information about the DApp, but disappears, so what’s left is the tag that people might serendipitously encounter if they overlap in behavior patterns.

Related: reminder that we planned updating DApps to Browser in the Tab bar (cc @rachel)

1 Like

The main constraint for the UI side is that it shouldn’t be like an appstore of a kind to have a chance to pass Apple’s review system. Probably friend’s activity is a good variant of that, but it woudn’t be unwise to have a few backup scenarios.


I’m not familiar with the Spotify activity feed as it requires a facebook account to use, but it sounds like the right direction. It could certainly start as an activity feed, and with tag categorisation/filtering, it could look somewhere between an activity feed and craigslist.

So the idea was that for discovery of a public chat, contact or dapp, someone had to publish it. This allows people to advertise their services (self promotion), raise awareness about interest groups (public chats), and/or raise awareness about dapps.

Think of it as

  • Bob creates a signed status (this is either a dapp url, a chat topic,and/or a string like “hit me up for the best #organic #coffee beans, #selling for for snt” along with their public key.
  • Bob publishes a set of statuses (payload) to his contacts ranked on his usage rules (top most is their own status), one of his contacts is Alice.
  • Alice periodically receives payloads from her contacts
  • Alice publishes a set of statuses (payload) to her contacts ranked on her usage rules.

So a status is less writing a graffiti tag on a wall, and more like the spread of the common flu.
I use the #organic #coffee snt here to denote a tag/category (although there’s issues with this and public chats).

Also I don’t think a status should be restricted to only a dapp, public chat or string, it might make sense to allow all 3 in one status. ie
#crypokitty (autogenerated for dapps)
“get your cryptokitty #collectable #dapp

If Bob was a DApp creator I would create 2 keypairs, one for my personal use, and another for my DApp. I would use my ‘DApp key’ to publish my DApp status. In future this keypair used for DApps could be used for offering support.


I support this idea. While researching about Liquid Democracy, I bumped into “Viscous Democracy”, which was not useful for me at Topic Democracy, but was very interesting anyway.

In a small research, I found out this could be very useful for content curation. The basic idea is that recommendations are based on user friends, which also have recommendation from their friends.
Is named viscous democracy due the property that recommendations from friends of friends have less priority than from direct friends.

In the implementation side, we cannot use directly blockchain due privacy, however each user can store their own ratings in a decentralized storage, as SWARM or IPFS, and the client could load for each friend their ratings and calculate a customized Dapp list.
To have viscous democracy, each user also includes the information calculated from their own friends. Listing the friends list in this file would give more consistency to the information, but it would break privacy. A simple solution to keep privacy and viscous democracy is to educate users to not include users which manipulate this file, or do some math tricks to filter out dissonant values.

This are more info about viscous democracy:

Instead of rehashing the issues around privacy, bandwidth usage, reliability, and the UI that we have discussed before on this, let me just ask one, noob question.

My impression with the current work is that the central premise is to separate Status from the DApps you can access through Status, i.e. make sure that none of them are in the native code we ship through the App/Play Stores, so that we reduce the chances of being banned there.

Would going for a friend-to-friend model then completely turn around our thinking (because the store would have to be native, no?).

My plan was to first integrate simple embeddable chats on following Richard and Iuri’s work, and then see if we could extend that and build some cool filter mechanisms off it, but I think these are 2 very different paths.

I like the “graffiti tag metaphor very much. Please can you sketch( really please draw some pictures!) up some use cases and anticipated workflows?

I’d like to have this a bit more concrete, but the direction seems awesome!

1 Like

Given some of the rules I set out, thats a fair point, it doesn’t have to be native though, it might even make sense to look at what kind of api is useful in the general sense.

But the other thing here is that this idea is so far removed from the dapp store concept they’re pretty much non-competitive, so much so I’m unsure if it would face the same challenge. This would be closer to twitter or a message board than an app store, that’s how different this idea is.

Any updates on this? I do really like this where and how can I follow along or contribute?

I think this is likely something we’ll revisit in Q3 or Q4, we want to solve some of the more immediate messaging problems first. :slight_smile: thank-you for your enthusiasm I really want to see it too, just watch this post I’ll be sure to update :slight_smile: