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.
thank-you for your enthusiasm I really want to see it too, just watch this post I’ll be sure to update