High level overview of a subscription protocol proposal

Developers Programs & Applications
1

The following is an initial non-technical specification for a protocol I am working on. I am looking for general feedback before I take too many next steps. There is a technical specification in the works but wanted to use this opportunity to get some initial feedback before too many things are solidified. I have listed a few concerns about the protocol at the end but I am interested in any concerns/problems anyone has on the general direction of the protocol.

Purpose

The goal of the {awesome_name} Protocol is to create a standardized model of communication between content creators and content consumers. In the current web model, the users and content creators are tied to an online service and locked into the service’s ecosystem. In the Web3 era of ownership and interoperability, this protocol aims to allow creators and consumers stay connected no matter what service is being used. In its most basic form, this protocol allows consumers to subscribe to any number of creators’ content. Doing so will push new content to wherever a consumer wants.

Overview

The protocol is designed to have many different online services be able to send new content to consumers with minimal implementation requirements. The online services that could use this protocol are services that host blogs, videos, podcasts, social media, or any form of content a user would consume. The service would do exactly it does right now except when new content is posted, that content would be sent to a subscriber directly (outside the service).

The content consumer end can also be implemented in any application with a minimal implementation requirements. All the application would need to do is be able to accept new content and then display that content to the user. It could be implemented as a simple standalone application or be integrated into an already existing application. A content consumer will also be able to directly react to content such as like, share, tip, etc… to allow for feedback directly in their content feed instead of having to go to each site individually.

On top of this the content creator can move the source of their distribution at any time. This means if a content creator no longer wants to post their content on Site1, they can move to Site2 and will not lose connection to their subscribers. The same goes for content consumers, they are not locked into a single application and can migrate at anytime.

The protocol can be thought of an RSS feed for the Web3 era with two way communication and real time updates.

Terms

Channel

A channel is a content source that outputs any media, such as blogs, videos, or social media posts. When a consumer subscribes to a channel, that channel will push its content to that subscriber’s feed.

Channel requirements:

  • Contain a function to modify a subscription for a feed
  • Send new content to subscribed feeds
  • Convert the content into a common format that the channel and feed both understand

The channel is tied to its owner rather than an application. A feed only checks for a valid owner on a message rather than the source of the message. This allows the owner of a channel to send content from anywhere, to any feed subscribed to that channel, meaning:

  • An application can upgrade its code without breaking channels
  • A content creator can switch online applications and maintain all their subscribers

Subscription

A contract between a feed and channel that defines what content the channel should send to a feed, and where to send it.

Subscriptions contain:

  • A callback function to add content to a feed
  • The feed owner’s identifier
  • Optional data to only include a subset of the channel content

Subscriptions can only be modified by the feed’s owner.

Feed

An inbox that can subscribe to one or more channels and receives new content from them through a subscription. Subscriptions can be modified to send content to a different application by the owner of a feed. The feed then can move between different applications with little friction.

Reaction

Reactions are optional callbacks that allows feeds to communicate reactions to content from a channel.

Examples of reactions include liking, re-sharing, tipping and commenting. Reactions are not required and are to be specified by the channel.

Content

Content is any form of media that a creator has made and wants to share with an audience. This can come in the form of text, html, videos, audio, etc… Each content update to a feed will have a standardized (but expandable) format so the feed will be able properly display all content.

Flow

Subscribing to a Channel

In order for a feed to receive content from a channel, the feed needs to create a subscription with it. The feed just needs to know is where that Channel is located and follow the protocol subscription parameters. Channel discovery is not defined in the protocol but things like a Channel Registry (see Additional Features section) can be used to lookup channels.

Once the feed makes a request to setup a subscription with a channel , the channel can decide whether to accept it or not. This can be useful for NFT gating, charging fees, or just making sure that both the feed and the channel use the same content formats.

If accepted then the channel must save the subscription information to know what feed to push content to and what content to send to it. At any time the channel may unsubscribe a feed for any reason. Some reasons may be the feed canister no longer exists, the feed owner no longer has the gating NFT or if the channel wants to purge subscriptions.

Each subscription can include filters to only subscribe to a subset of the channel content. This allows a channel to have as much content as they want while also allowing a feed to only receive the content it desires.

Posting new content to a Channel

When the channel posts content, it sends the content (or a link to that content) to all feeds with applicable subscriptions. The feed should validate that the content is from the channel creator (signature) rather than from the application the content came from (cannister id). This allows content creators to be decoupled from any application.

Reacting to Channel content

When a user is consuming content they can respond to that content with a specified list of actions provided by the channel. Examples can be likes, shares and comments. This is an optional feature that is specified by the channel.

Updating a subscription

At anytime the feed can modify or cancel the subscription to a channel. The user just needs to resubscribe with the proper info and prove they own their feed (signature). This allows the channel to know that the request is coming from the same user that originally created it.

Protocol Flexibility

The protocol is designed for flexibility to allow it to evolve over time and for features to be easily implemented on top of it. To do this, certain aspects of the protocol are open-ended.

Content, signatures, and reaction formats have initial specifications but allow for additional formats that don’t currently exist or are only specific to certain applications.

During the subscribing process, the formats to be used for communication are agreed upon by the channel and the feed. This allows channels and feeds to add new features but fall back to a simpler format if not supported by both.

Protocol Extensions

Channel Registries

The ability for feeds to discover channels isn’t directly a part of the protocol. This can be solved for by using one or more registries that contain basic information for a channel, such as locations and content descriptions.

User Identity

An important part of user interaction or discovery is knowing what users are a part of channels and what users are consuming the channel content. This is not built directly into the protocol due to there being many identity services and protocols, but this protocol design will include extendable aspects to integrate user identity.

Minimal Implementation Design

The simple design has 2 canisters, one for the channel and one for the feed

Setup subscription:

1
1760×466 21.8 KB

Content consumption:

2
21515×466 34.2 KB

Sources of Inspiration

This protocol is inspired by ActivityPub’s federated protocol and RSS feeds.

ActivityPub tries to connect social media networks with a common set of rules and structures but is challenging to implement because it requires services to be designed from the ground up around the protocol. The {awesome_name} Protocol is designed as a small extension that can be added to an existing service.

RSS feeds are a simple but outdated standard provide limited functionality beyond sharing updates between websites when a consumer requests (polls) those updates. {awesome_name} Protocol allows for the ability to get insights on who is consuming content and allows those consumers to communicate with the content creator.

Concerns with Protocol

Adoption by content publishing services (monetization)

Due to Web3 being so new this one is my biggest concern. If this were a Web2 protocol, it might not work because of the dependence of ads to online services. This protocol might get in the way of content consumers getting all their content from the site directly, which is needed so eyeballs look at the ads and suggestions the site displays.

The HOPE is that Web3 monetizes a different way than just advertising but even if it doesn’t, my assumption is that most sites will want someone on their site more than a feed off their site. So will having a protocol that needs to be implemented by content sites work out if there is a down side for it.

That being said, there are some advantages:

  • Smaller sites can have a larger user base since they don’t have to compete as hard against the top site
  • Content publishing sites can implement a feed into their own site and have both content publishing AND content consuming. There could be competition of who has the best ‘dashboard’ for content consumption

Social Media

This protocol focuses on publishing large pieces of content but may struggle with some social media with small and frequent posts. The idea was that this protocol could unite ALL online content publishing services, but if connected to something such as Distrikt or Seers it could(?) be overwhelming unless bundled together. There are possible solutions but this is the current state of the protocol.

8 Likes
2

I think the following thread is generally relevant but particularly this comment:

1 Like
3

Excellent post, thanks for taking the time to dive deep and start the conversation :clap:

Have you thought about how the new Proposal: Composite Queries feature might improve or hinder this protocol? How might applications and user owned data “canisters” or services handle cross subnet limitations and the latency involved?

Also I’d assume that for safety against malicious canisters, this use protocol might use a series of one-way calls as mentioned by @nomeata in Zero-downtime upgrades of Internet Computer canisters – Blog – Joachim Breitner's Homepage.

1 Like
4

I assume that this would be an SNS protocol / token on the IC. With respect to monetization, I have a follow-up question that is perhaps more targeted towards the broader IC community. The answer to that question could help address the monetization concerns in this proposal too. In short, what options do SNS entrepreneurs have to monetize their service offerings in the soon to be launched SNS ecosystem?

Would end users (like investors) buy their many different SNS tokens and then be charged a gas fee using those various tokens? Alternatively, if a reverse gas model also applies to SNS tokens like it does to ICP, then would end users pay the SNS service provider in Cycles, which the provider could then burn as needed to deliver the services? If the latter scenario applies, I think this could only work to offset costs, since any profit from Cycles billed less Cycles burned can never be converted back to ICP or any other currency.

I apologize if this sounds like a very basic question, but I haven’t seen anything yet on how all these SNS token economies would likely work under the IC umbrella from a monetary flow point of view. If there is not an easy, built-in process for creators and SNS service providers to be paid and make potential profits convertible to fiat currency, then I don’t see how the SNS ecosystem can get off the ground very easily.

5

@paulyoung I was actually thinking about the whole ‘owning a canister’ thing and I don’t think it needs to be a part of the protocol and I dont think the user would need to own the canister.
As long as the ‘channel’ and ‘feed’ sign their messages with the users identity, the canister can be owned by the application. If a user doesn’t like the application then they can move their channel to a different one or one they own if they really want. Though all this is in theory/still working on the spec, I think the concept of ‘true ownership’ of the whole canister can get in the way of the application

6

@icme im not sure I fully understand the connection.
At least for the minimal implementation there shouldn’t be multi canister queries or queries in general. The channels would push out their content to feeds so the feeds dont have to query the channel itself.
Im trying to make it so that the channel/feed are not tied to a canister but rather a user signature or something for user ownership. Much of the security/implementation details are just left to the application to handle

1 Like
7

@Sabr Currently I have no solid plan for monetization. Since the protocol isn’t actually an application but a standard, it doesn’t seem straight forward to have an SNS for it.
The only things I have come up with so far for an SNS are

  • Channel Registry, a centralized lookup of different channels that one could subscribe to
  • A feed/reader application, at least have a reference implementation of a feed application

As far as the tokens, i dont think that services would need to rely directly on their tokens to do things. Taggr.top seems to use cycles for using the service vs a specific token, though that might change after the SNS. I think post SNS launch we will see how some of these models will turn out. It seems that monetization can take any number of forms, not just with tokens. The IC allows the application to handle all the cycles and get value from their customers in other ways to balance it out or have the user directly pay for usage. But this does touch on my concern with the protocol because there is so much unknown right now and anything can happpen

8

@Gekctek, it sounds like both of us are waiting on someone from Dfinity to explain how the tokenomics would likely work for service providers post SNS launch. Given that almost the entire value of ICP as a utility coin hinges on the burning of ICP by the SNS ecosystem (= ICP “revenue”), I think it is important to explain the following: 1) how an SNS would typically make a profit via their token or ICP; and 2) how an SNS could regularly convert that profit into currency to pay their ongoing bills, including both ICP utility cycles and the living wages of SNS founders/workers (i.e., beyond the sweat equity startup period).

Based on my understanding, Dfinity is at least implicitly claiming that the SNS ecosystem can replace the entire VC/PE and IPO/ICO funding models while meeting a wide variety of founder financing needs. If so, then they definitely need to elaborate on the logistics of this SNS ecosystem model further before any wave of would-be entrepreneurs is willing to jump on the SNS bandwagon.

Perhaps @diegop knows of someone at Dfinity who can explain how SNS tokenomics would most typically work once this ecosystem is launched. Again, I feel like I’m asking a stupid question here, but I haven’t found any clear answer yet, including in the IC Wiki.

1 Like
9

This is not a stupid question at al @Sabr. Let me ping some folks at DFINITY who I think can have much more clarity of thought on this than I can.

2 Likes
10

Hi all,
regarding the questions on a framework for SNS tokenomics.

An introduction to SNS tokenization (covering pre-deployment considerations, an overview of tokenomics concpets and a description of SNS voting rewards) is here.

Some key points to note:

  • As part of the decentralization sale of a dapp, participants can invest ICP and receive SNS tokens/neurons in return. The collected ICP goes to the SNS treasury and can be used e.g. to pay for cycles.
  • After the the sale, the underlying dapp is under the control of many different parties (in particular also the sale participants).
  • The SNS treasury can keep a (significant) amount of the initial supply of SNS tokens which can be used to reward users (e.g. for active usage) and also for for dapp enhancements (e.g. code bounties).
  • The SNS can decide via voting how to use & allocate its funds (ICP tokens, SNS tokens) in the SNS treasury. Via DEXs, recipients of tokens can exchange against fiat or other tokens if desired.
2 Likes
11

@bjoernek to be fair, I think @Sabr 's question is more simple and perhaps closer in spirit to the following:

“If I launch a decentralized Twitter via SNS, what are ideas of how it can be self-sustaining, pay for its own cycles, grow, make money, etc… without VC funding or Web2 style revenue models?”

I do not think @Sabr is asking in absolute terms, but more what are some example ideas people have.

Did I capture your intent @Sabr ?

1 Like
12

Thank you, @bjoernek. Your explanation and link were quite helpful, along with 2-3 other links that I jumped to from your link. I did not read these before.

It appears that buying the initial SNS tokens requires the intermediary ICP token. That is good for ICP demand and ICP lockup, especially since ICP would likely comprise the bulk of the SNS treasury for future cycles and dapp enhancements (paid to developers). I am assuming that SNS tokens could then be traded directly for any other token on a DEX, which means ICP would no longer be required as an intermediary coin to eventually convert an SNS token into fiat currency (e.g., for a developer to pay his or her monthly rent). That makes sense, but please let me know if I have misunderstood this point.

I also like how the majority of initial SNS funds go either to the SNS treasury or to external parties (customers and investors) to prevent a rug pull by the developers. However, will this majority distribution be mandated by the NNS, as Dominic appears to imply in one of his videos (I can’t find the link right now)? Also, would this majority mandate apply to the circulating supply or to the total supply? The latter would include any SNS tokens sitting in treasury, on behalf of which no one could cast any votes to offset a potential rug pull by the developers.

Overall, I like this framework a lot. However, one big problem that I still see with it is that an approval voting process is not suitable for prioritizing the allocation of resources among >2 competing alternatives (e.g., >2 projects of differing value and risk, or >2 developers who contribute value at very different expertise and commitment levels). I brought up this same point for the NNS in multiple posts, such as this one, which was my very first post on this forum 15 days ago:

For the NNS, this collective prioritization problem is not yet urgent due to the lower risk startup stage of the IC, the IC’s nonprofit status, and the existence of a very large and reputable team of individuals currently making the prioritization decisions for the IC within their various dictatorial silos of expertise. By contrast, an SNS would typically be a for-profit organization, where a single entrepreneur would make the many dictatorial prioritization decisions that an approval voting process cannot make collectively. That involves significantly more immediate risk to investors.

This is why I suggested that Dfinity begin to experiment with computational social choice approaches to address this “prioritization chasm” in collective decision making. This chasm currently applies to all DAOs, not just to the NNS or every SNS. I would be open to collaborating on this as part of my PhD research starting next year if there is some interest at Dfinity. In particular, if there is anyone at Dfinity who has some expertise or familiarity with either social choice theory or computational social choice, I would very much appreciate it if you could connect us so that I could discuss whether a collaboration might make sense.

Keep in mind that the breadth and urgency of this “prioritization chasm” grows as an organization becomes larger and larger. The number of resource allocation alternatives and tradeoffs generally grows exponentially and becomes more and more complex, with many overlapping silos of functional expertise.This chasm could take years to cross given the long history of this problem, so I would highly encourage at least some preliminary discussion and experimentation, sooner rather than later. Without solving this problem, DAOs can never be truly decentralized with respect to the most important decisions an organization can make, which inevitably require critical tradeoffs and prioritization.

@diegop, I just saw your post as I was about to hit Reply. I think @bjoernek answered one typical way an SNS could be self-sustaining. However, I too would be very interested in any different ideas that others have, especially ideas from entrepreneurs planning or considering a launch of their own SNS in the future. I am not sure if the typical funding model outlined above could address all of the scenarios that entrepreneurs have in mind. Thanks for highlighting this point from my prior reply, which I forgot to mention again in this post.

1 Like
13

Yes, your understanding is correct.

In order to be decentralized from the start, it would be required that the majority of the voting power is in the hand of the community. For example, you could imagine a set-up where 30% of the initial supply goes to the community (in the form of neurons), 20% to developers (in the form of neurons) and 50% remains in the treasury. In such a set-up the community would have the majority of the voting power (but not the majority of all tokens). The remaining tokens in the treasury could then be distributed over time as usage rewards to active dapp participants.

In terms of your other inputs on how to set up a SNS: I have started putting together some initial material describing on what to consider when establishing an SNS with respect to tokenomics/incentives and plan to share this soon with the community to get feedback and to iterate. Your feedback on that material would be appreciated!

1 Like
14

Thank you, @bjoernek. I think you have addressed most of my initial queries, particularly with respect to the majority voting power issue. It is wise that majority voting power should always be in the hands of the community to avoid the worst case scenarios from bad actors, which would indirectly “poison the well” for the IC and the NNS. I would be happy to provide feedback on the SNS tokenomics/incentives material once you have it prepared.

1 Like
15

Update - Putting this idea on ice

TL;DR
Over the last few months I have been playing with this idea but the following has made me rethink this for now:

  • Protocols/standards aren’t necessarily hard to do in implementation, its adoption and working with others that makes the process tedious. I am a developer, not a people person
  • Some of the ideas such as reactions have complications such as reducing incentives for sites to use them due to people not going to their site and staying in an app and increased complexity
  • There are too many cool things to do in the IC ecosystem, I don’t want to be tied to this even though it is important to have

Details:
To recap on the overall vision:
Right now there is aren’t ways of to let users know about new content except for 1) going to the site, 2) social media. If im interested in following something, lets say Taggr posts, then either I have to goto Taggr all the time. Since there are many sites I would want to goto, I dont want to have to go to each one and find the content that I want. There should be a way to see all the new content in one place, whenever I want to look (not constant notifications).

The idea ended up looking like web3 RSS feeds. So much so that I used this as an opportunity to use RSS as the starting point of the protocol. I did this by creating a prototype RSS feed canister that would fetch RSS feeds on a regular schedule (since RSS is a XML file that gets updated vs push notifications) and allow people to subscribe to the RSS feeds that they wanted to.
This KINDA works but there are some issues, the main one being cost. HTTP out calls are more expensive than I imagined they would have been. To make them cheaper you have to get the smallest amount of data as possible and predict the max size of that data. Since the data is unpredicatable, large due to lots of text and constantly updating, it didn’t seem to work. Also if I wanted to offset the costs by charging users for it, how would payments work? Would it be cheaper to subscribe to a feed that 1000 people subscribe to vs a feed that no one subscribes to? How are they paying? Are they just putting in a lump sum to be deducted by the constant polling of the RSS feed?
Also there were some issues around lack of Motoko libraries to help with the XML/RSS parsing so I opted to do an oracle method for the prototype. The oracle works by having an off-chain server that looked at the subscribed feeds in the RSS canister, making the http call, parsing to the protocol format, then pushing the data to the RSS canister. This has worked and I have been using it as an RSS feed reader but I have stopped there.
As said above, there are too many non-coding things to do to have this adopted by services and its so early that its hard to say what the protocol should be since things can change so fast. I am making this post for posterity/anyone looking to do something similar.
For those interested here are the repos I have been using:
Motoko/Canister: GitHub - edjCase/subscription_protocol
C#/Oracle: GitHub - Gekctek/RSSOracle

Also my site exists for those who are interested. That being said, my current plan is to just let the canisters run out of cycles
https://unsv4-2qaaa-aaaad-qenoa-cai.ic.fleek.co/

1 Like