Incentivising Seed Nodes - The Next Challenge for Radworks?

[lftherios]

I’ve done more thinking over the last few days and this is where I stand.

I would like to propose that we create a new org within Radworks that will focus on Gateway / Seed Node Infrastructure.

Purpose

The purpose of this org is to provide gateway infrastructure that makes hosting and fetching content from Radicle simple, performant and accessible for any developer.

What

For 2024, my proposal is that this org should focus on two services:

1. A centralised gateway service that offers a) storage for Radicle projects and b) bandwidth. The offering should be provided for FIAT or crypto. The focus here should be on convenience.

A centralised gateway service for Radicle refers to a web-based service or server that allows users to access and retrieve content from the Radicle network through a centralized point of access. An example from the IPFS ecosystem is Pinata.

Accessing content directly from the Radicle network can sometimes be less convenient, especially for users who are not familiar with Radicle or don’t have Radicle software installed on their devices. A centralised gateway service provides a bridge between the traditional web and the Radicle network. It typically works as follows:

• User requests content stored on the Radicle network.
• Gateway service resolves the request: The centralised gateway service receives the request and resolves it by fetching the corresponding content. It acts as a middleman between the user and the Radicle network.
• Content is served to the user: Once the content is retrieved from Radicle, the gateway service serves it to the user’s web browser or application just like any other web content. The user can view or interact with the Radicle-hosted content without needing to install Radicle related software.

2. A decentralised version of the above service that focuses on a blend of censorship resistance and performance. This network should be coordinated via our native token RAD.

A decentralised network of Radicle gateways, also known as seed nodes, refers to a web-based service where users can purchase bandwidth and storage using cryptocurrencies, specifically stablecoins. Additionally, this network allows anyone to operate a node and earn tokens by serving Radicle-related content. An analogous service in the IPFS ecosystem is Saturn.

I can expand on the above based on your questions.

Why

My primary rationale stems from the following observation: Radicle’s gossip-based peer-to-peer network suffices adequately in terms of performance for individual / hobbyist users. However, when considering professional developers, performance & convenience become significantly more crucial. Consequently, it is only natural for a demand for self-hosted or 3rd party gateways to arise. This phenomenon mirrors what has occurred with IPFS, Scuttlebutt, or any other peer-to-peer network that has gained adoption, so it’s fairly proven.

When it comes to this audience I believe that is wise to offer two services (one centralised targeting convenience and one decentralised targeting a blend of censorship resistance and performance). My thinking is this:

• if you care about performance: Radicle + 3rd party gateway > Radicle + decentralized network of gateways > Radicle’s gossip based network

• if you care about censorship resistance for the content of your app: p2p gossip > Radicle + a decentralised network of gateways > Radicle + 3rd party gateway > postgresql operated by a company

With regards to the decentralised offering that I describe above, my hypothesis is that there is a large number of well funded crypto related applications and protocols that care about censorship resistance but are looking for something more performant than p2p gossip and something more decentralised than relying on a single gateway (3rd party or self-hosted).

Achieving the centralised offering is in my opinion well within reach, and I have a high level of confidence in our ability to swiftly deliver a great service. An initial centralized offering will provide the necessary resources and time to thoroughly investigate the demands and viability of the decentralised offering. While the decentralised option is more intricate and ambitious in nature, it strongly aligns with Radworks’ values and overarching goals. I also think that this is the most natural sustainability model for Radworks and I am excited for Radworks to move beyond its current form.

Why now

With Radicle 1.0 a few weeks away and with Drips already in production the vision we set to deliver in 2018 is now in a really good place. So we have to think about the next challenges and opportunities for our oganisation and I believe that these are:

1. to bring Radicle and Drips to millions of developers globally
2. to scale our infrastructure to support that and
3. to make Radworks sustainable for the long-term.

I believe this proposal enables us to address the immediate needs of Radicle users and explore more innovative approaches for node coordination simultaneously.

Who

I’d like to propose that I kickstart this team. The objective would be to swiftly onboard three senior engineers to commence work on this topic, while we also outline a detailed strategy and execution plan for the year. This also includes identifying and hiring a future team lead who will eventually succeed me in this role, as I already have a substantial workload to manage between Drips and Radicle.

I am ready to flesh out a more detailed proposal that follows the Radworks format that we used in the past but first I would like to receive more questions and feedback.

[yorgos]

Very interesting stuff here @lftherios !

@lftherios

• An end user pays a fixed price for hosting and bandwidth, so they don’t have to think about dynamic pricing and similar complex things.

I think I particularly like the “fixed price” direction, but let me understand it a little better first:
would it be the same fee if my repo is 100MB and if my repo is 10GB ?

Also, just to clarify, is this pricing model still relevant after the latest updates to this post and the proposal for the centralised gateway offering?

@lftherios

I would like to propose that we create a new org within Radworks that will focus on Gateway / Seed Node Infrastructure.

Disclaimer: In the text below, “org” is used loosely and in its lowercase format on purpose. The recent governance discussions revealed there are different points of view on what an ‘Org’ is and it is not my intention to further elaborate on that discussion here. With that said:

This makes a lot of sense, and, as one of the very few (less than 10) active node operators, I am in support of this initiative, because:

1. it helps with separation of concerns and reduces conflict of interest,
2. it is based on the well-established model of hosted open source service offerings (and Software-as-a-Service (SaaS) companies, in general), that allow users to easily “try before they buy”
3. the timing is right: it makes sense to do this now

I will only very briefly expand on each section, just to help clarify my point as this is all in agreement with the proposal anyway.

1. Separation of concerns

With the protocol being decentralized, it is somewhat contradictory to have the same team that is developing the “fully decentralized” protocol to also operate the public seed nodes.

On the one hand the team is developing the protocol that needs to serve all node operators equally, but there is an inherent conflict of interest if the protocol team is also a node operator itself (meaning it could prioritise work that serves its own interests as opposed to those of any node operator).

This way, it will be easier for the protocol team to stay impartial and focus on protocol development.

On the other hand, the “Seed Node Infrastructure” team can focus on the actual service being offered to end users, focusing more on UX, smoother onboarding, community support and customer service and so on - maintaining a much more user-focused position.

Looked at another way, we can identify two different types of stakeholders here - “node operators” and “end users” - and it makes sense to me that each org - protocol and seed node infra - is clearly positioned to serve the needs of each type of stakeholder, as a kind of “internal customer”: protocol team → public node operators → end users.

@lftherios is this in line with how you were thinking about the positioning this new org?

2. “Try before you buy”

It is a well established pattern for many open source projects to offer a hosted service as a quick way for end users to get acquainted with the project and try it for themselves before they decide to self-host and deal with the operational complexity of self-hosting.

End users are generally comfortable using such hosted services because:

• they can reduce the investment / learning curve on this new piece of software, as they have less to learn (i.e. it is not just “more performant”, it is also “easier to use”),
• they can find out if it is a good fit to their problem faster,
• it is a nice way to support financially the maintainers/creators of the project,
• there is no vendor lock-in, as they always have the option of self-hosting.

Equally, I think this will also help node operators in deciding whether they want to be involved with running Radicle nodes, because before deciding to offer / sell any service it is important to understand the service / features / advantages of whatever it is you’d be selling to your potential customers. Not having to self-host, to find that out, makes that path shorter.

Something worth thinking about here however, once we have the centralised service, is how we’ll protect from “The Amazon Problem”: The Amazon Web Services (AWS) practice of finding established open source projects with a hosted service and then offering the same service on AWS - essentially luring all customers away from the centralised service offered by the project maintainers to its own hosted service. (e.g. see Mongo, Elasticsearch, etc. etc. ). The “decentralized service” you’re proposing here might be able to help here (and we might be in a unique position to defend from that problem that other non-decentralised projects aren’t in), so this is definitely something worth exploring further.

3. Timing

With Radicle essentially not having hit general availability yet, it seems to me that moving forward with this initiative will essentially lay a much smoother onboarding path for new users, assuming this new org is more focused towards that.

In addition, there is currently no established node operators network. There are only a handful of public nodes (most of them operated by the Radicle Org, or its team members), so there is essentially no established competition between different entities at this point in time. If this happened 6 months in the future, when some hosting companies might have started investing in “hosted Radicle” services for their customers, such a move might be seen competitive to those community members. Doing this now allows us to set a different stage so that doesn’t happen.

Finally, this new org could contribute to the community important work around different ways to deploy Radicle in different environments (cloud, on-prem, containers, native, home lab, etc. etc.) with more docs, deployment scripts and general operational know-how. There is only very sporadic information right now about this and very limited deployment options in general.

---

Thanks for your work and all these thoughts in this area! Very interesting stuff!

[vanton]

It’s a nice idea @lftherios

A centralised gateway service that offers a) storage for Radicle projects and b) bandwidth. The offering should be provided for FIAT or crypto. The focus here should be on convenience.

The first thing I am trying to figure out is what are the characteristics of the target market of this product/offering. As far as I understand, the centralized offering is primarily aimed at organizations or individuals who are not yet ready to commit to running their own Radicle nodes. This could include smaller teams, companies that are experimenting with Radicle, or developers who simply want a more convenient option. By providing a hosted service, Radicle can make its platform more accessible to a wider audience and help it grow its user base. So, although it is not 100% aligned with Radwork’s foundational beliefs it is a stepping stone for the decentralized network.
The most important benefit in my opinion is that if this offering does what it promises radicle will get valuable feedback to validate and prioritize its product roadmap.

I would like to propose that we create a new org within Radworks that will focus on Gateway / Seed Node Infrastructure.

Splitting the Seed Node service into its own organization is a wise decision, as long as the two entities focus on distinct products and offerings that cater to different needs. In this instance, the Seed Node org clearly aims to address a problem that is related to but distinct from the one that the core Radicle project tackles.

From my point of view it presents a new potential for Radicle adoption.