I’d like to gauge community sentiment on whether or not it’s appropriate or beneficial for the community to build an alternative web presence to rocketpool.net. This is largely an extension from this thread by @knoshua: Can rocketpool.net be open source?
Some background: we’ve had solid community efforts in terms of branding and website building – notably from Sleety, @coop.eth, and @ccleaver.eth. You can see examples of these here, here, and here. There is also a strong community interest in getting an open-sourced website for transparency and community contributions, and an alternative front-end to the official site for decentralization.
Here is the list of pros (+) and cons (-) as I see them.
+ We could dramatically improve our web presence.
+ Taking contributions from the community would enable us to move faster on website updates.
+ This could potentially take some burden off of the core team and enable them to focus on other work.
+ It would help contribute to a healthy decentralized and community-owned protocol.
+ .fi is much better than .net in my opinion.
- This may duplicate effort, or create points of friction with the core team.
- It may introduce new security risks if we’re not careful (DNS, bad PRs).
- It may create branding confusion if we diverge from the official branding too much.
Yes, we should do this
No, it’s not worth it
0voters
To be specific, I registered the rocketpool.fi website over the summer, and currently have it pointed to a GitHub pages repo that could take PRs from the community: GitHub - InsufficientlyBullish/rocketpool.fi. We could potentially build on this to make a new web presence.
In particular I’d like to get the team’s take on this idea (@nickdoherty, @langers, @maverick). Would you support it? Take steps to distance from it? Endorse it?
I too would like to get the core team’s thoughts on the idea, but I am tentatively in favor. With liquidity incentives up and running, LEBs on the way, grants/bounties about to on the way, and Mav on board for marketing, the website seems to be the community’s biggest pain point at the moment.
It definitely has my support, because we need a trusted backup in case the current one gets shutdown for whatever reason. I’d change my opinion if it gets open sourced.
I’m a technical analyst first. Accordingly, I’ve always thought that, while rebranding might be a nice-to-have, it generally wasn’t the most important element of our fundamentally technical protocol.
That said, I’ve had my view on this changed a bit over time. I’m colorblind, and it seems obvious the current orange branding bothers others more than me. The original branding was created in 2017, and I’ll admit that, while 5 years certainly makes a difference in the design world, it’s an eternity in crypto.
Another point in favor of a community-made site is even more convincing to me now: resilience. We’ve seen the importance of decentralized front-ends as censorship resistance has become a less ideological and more serious topic in our industry.
Liquity is a model project in this regard. They have explicitly chosen NOT to create a front-end app, and I now believe that this is the best model for all low-level protocols. Like Liquity, however, RP still needs a website which is the canonical source of information about the project, so I do think we should collaborate with the the devs to transition the existing site to an open source project.
The dev team has expressed security concerns with opening up the source code for the site, which is reasonable. However, it’s only fair that users should be able to audit the full RP stack all the way from webapp down to the smart contracts. Copy-cat scam sites are another concern, but if we move to a “no canonical front-end” model, this isn’t an issue.
Changing to this model is a long-term goal, however. In the short term, I’d like to see the non-app elements of the website open-sourced. From there, the pDAO can encourage the development of alternative front-ends for RP interaction and eventually deprecate stake.rocketpool.net in favor of a page similar to this one from Liquity:
The community is a distinct entity from the core team and should have its own voice. This doubly (or even triply) applies for the pDAO, and though the pDAO and community are not equivalent, they could overlap in terms of web presence, which pDAO without doubt will need. Not only do I think there should be a community/pDAO site, but that it should be distinct from the official site.
Further, there is a massive amount of hidden information, data and experiences the community has built that are increasingly difficult to track down. Whereas the official site should be professional and limited in scope to the direct message and technique needed for engaging the Rocket Pool protocol, the community site should be broad and diverse, including access to this wealth of community created utility and entertainment.
Imagine Apple had two completely different looking sites.
apple.com is orange and apple.net is blue. Both have different presentation, a different degree of details about Apple. They even have different parties involved, one by the official Apple company and one just from a bunch of coders working together.
Apple would have never been able to get the customer’s trust because “which site should I even use?”
So, here are a few bullet points:
How would you market a product with two completely different websites?
Do the devs of the current site need to consider the OSS site before making changes?
Maybe it could be done that both sites have clear, different purposes (e.g., the current one is for technical details, the OSS one is only added community information)
We should not constantly change websites and their designs. At some point we need brand awareness.
Is it possible to provide functionality of the current site as an open source component so the OSS site could use shared resources?
For me, there’s too many questions to really support this. If it was done in an intelligent way such that components would be shared between the two sites and we have a clear plan on how to inform people about it, then I think it would be cool.
But that would basically mean that we would need an RPIP specifying how the OSS page can incorporate pieces from the current page, what responsibilities the core devs have towards this new page, how we make sure it still represents what we as a community want and agree with, etc.
If for example somebody would add an address which people can use to help the Ukraine, then half of the devs would support it, the other half wouldn’t. If this happens, we suddenly have 3 pages.
So, if we as Rocket Pool endorse an open source site, we need to dictate clear rules what is accepted and what not.
It would be a great look for the protocol. Just like rocketscan is an amazing addition, a second website would add to the resilience of the protocol and show the strength of the community.
Remember we’re really web3. The website is not the real thing, it’s just a convenient way to touch the smart contracts. Literally anyone can make a front end if they wish to. They would have to keep up with smart contract updates, but that’s about it.
I don’t have a terribly strong opinion here, so mostly sitting out, just wanted to point out precedent (though in that case Liquity very much went out of their way not to prefer a front end).
Agreed on the points of decentralisation and innovation. The team have shown that they are resistant / cautious / slow to changing the website, and so a community-led website could offer greater integrations with other community resources and introduce new features more quickly. A nimble and sleek website in the current crypto environment is better than a 5-year-old website that looks sus.
I do think the arguments around confusion as to the official site are valid and how this could, ironically, create greater feelings of scamminess with two websites both offering the same or similar interfaces.
IMO, this is the real reason to build a community website. Look at how important https://rocketscan.io has become. As far as I know, @peteris didn’t ask for permission to build it, it has a great UX, and if we left building its functionality to the team, it would still be backlogged.
Now imagine if community members could contribute features to a website with reusable design, functionality, and components that they didn’t have to test and host themselves. Better yet, since it will all be open source, they can use as much or as little of it in their own apps as they want to.
We could instrument the site with analytics and run experiments just like any modern tech company does. For example, we could design variations to how rewards are presented and A/B test them. Highly successful designs could be exported back to the official Rocket Pool website too.
For what it’s worth, in most cases I don’t think the solution to potential user confusion is to fundamentally change what you offer to them (e.g., two functionally-overlapping but distinct websites with similar URLs). There is almost always a better design that mitigates the confusion, you just have to find it, in my experience (e.g., maybe the URLs/presentation should not be so similar). Along these lines, I think we should separate the question of whether to build a community site from the question of where to host it (whether rocketpool.fi is the ideal user experience may not be straightforward, but it’s fair to assume that a good user experience can be found).
I want to highlight @langers’ commentary from the latest Twitter community call that an open-source website would make it much easier for malicious actors to launch copycat websites.
I would agree that this is a primary concern that should be addressed, not just for open-sourcing rocketpool.net, but launching an official community website too.
I think launching a decent copycat is already doable in a couple of hours for folks with appropriate skills (the first time, and any relaunches on other domains are essentially no time). The nature of front ends is that they have to show the results to users, so the users get the data to make it.
The most natural way of achieving this IMO is by using the deposit fee as rETH referral incentive and increase its value from 0.05% to 0.25% (as proposed by @knoshua on the rETH referral thread: Discord).
This way websites would be competing for traffic and would also have some organic incentive for independent marketing.
I don’t like the idea of the rETH deposit fee going anywhere but to the burn. It would create perverse incentives. For instance anyone who could “spin up a website” or just use their own address as the referral would be able to sandwich rETH every day or get closer to doing that. The value from the deposit fee is currently spread out among all rETH holders because some rETH burned, and I like it to stay that way.
Nevertheless I am supportive of any open source front end. I don’t think the copycat website concern holds much weight as long as we are able to communicate the correct domain. I know it’s not difficult to make a fully functional copy of closed source websites.
I don’t understand what you mean by “sandwich rETH”, but it seems like you think they could profit just by minting rETH. This wound’t work, since the deposit fee would be taken from their own deposited ETH with net zero return for them. Of course any mint using the original website would still be directed to existing rETH holders.
We might want to make this idea into a different thread. But yes they could profit by minting rETH immediately before the ratio changes and then selling it after. If the minter has access to any part of the deposit fee this sandwich attack becomes profitable.
I think we can build front ends without expecting any profit. We would just need someone to donate the hosting costs or get funded from the part of the pDAO that handles the funds.
While I’d prefer the team to open source the current website, I support a community led effort to develop a parallel front-end for resiliency and testbed purposes.