I was trying to understand the vision of your protocol. It's very tough to do so, which is why I went to AI. You guys do the same for articles, copy etc. So I don't get the reason for throwing insults. The code is code, open source and public. If these are not concerns, then they should be easily addressable. Every finding links to file paths with line numbers. The concern is gaps in how the product is pitched and how it actually appears to work today.
If self-sovereign is an option, just say that. Explain the defaults, the reasoning, and the way to opt out.
Yes AI found these, but neither of you seem able to address them humbly or professionally:
- Session secrets in unencrypted MMKV storage? Why? that's a security decision that affects every pubky-ring user regardless of how they sign up, and it clearly contradicts the article pitching it.
- Cloudflare binary downloaded at runtime with no checksum? Why? That's a supply chain risk for every Umbrel self-hoster.
- Neo4j shipping with hardcoded password? Why? The comment in the code shows the team knew the default. The comment also warns that changing it post-deploy is non-trivial. Self-hosters who don't know to change it have their entire social graph exposed. Is this also wrong?
- GCS backend with no auditable configuration surface? Wrong again? Is there a configuration surface? Should be easy to just say so and show it. Synonym's production bucket configuration is not public, which helps explain the need for the ToS in the first place.
- you said users have a choice where their data is hosted. True for the homeserver. But is there a credible alternative to Synonym's Nexus for discoverability? Without it, content exists but nobody can find it. Self-hosting a homeserver without an accessible Nexus isn't a real credible exit for most users.
These aren't philosophical objections to the vision of 'your' protocol. They're specific, sourced findings that the "users have a choice" framing doesn't address or hold up against. I'd be happy to turn any of them into proper GitHub issues if that's more useful than a Nostr thread.
Login to reply
Replies (1)
> secrets in unencrypted MMKV storage
This could probably be improved. We're taking it up, thanks for the report.
> - Cloudflare binary downloaded at runtime with no checksum? Why? That's a supply chain risk for every Umbrel self-hoster.
Very much work in progress, we haven't announced the Umbrel integration anywhere yet and are still in development. For now we recommend not to use that project yet until we release our first Alpha version.
> Neo4j shipping with hardcoded password
User is encouraged to configure his setup when self-hosting. Don't open up your machine to the internet without understanding what your doing. No big difference to many other systems. A password change could be enforced, there is room for improvement, yes.
> - GCS backend with no auditable configuration surface?
GCS is an implementation detail of one hosted deployment (Synonym), not a requirement of self-hosting. Our vision is to have many independent operators to run instances on infrastructure they control, using whatever platform fits their needs. We can provide deployment guidance, but operators ultimately control their own configuration. Real self-sovereignty comes from the ability to self-host or choose a host you trust, not from visibility into any particular operator’s production config. We may explore additional transparency and deployment documentation in the future.
> - you said users have a choice where their data is hosted. True for the homeserver. But is there a credible alternative to Synonym's Nexus for discoverability? Without it, content exists but nobody can find it. Self-hosting a homeserver without an accessible Nexus isn't a real credible exit for most users.
Discoverability does require indexing. A homeserver can host your data, but an app still needs some way to aggregate and process the data. Simple apps can often do that on the fly; For more complex apps it's a good idea to externalize that work into an asynchronous indexer, otherwise the user experience becomes slow or incomplete. That aggregator / indexer can be run anywhere. It could be self-hosted (even though that's not yet as trivial as we'd like it to be). For pubky.app that aggregator/indexer is called Nexus. any users may choose a managed Nexus because it is convenient, while others may prefer to run or use an alternative operator’s Nexus.
Many people run their own Bitcoin node, but for indexing they still rely on 3rd-party-hosted block explorers, even though they have all the raw data locally, but they don't want to run the indexer themselves. Offering indexing for self-hosting as well as providing a well-run default seems like a fair deal to users. Do you think it should be done differently?
> These aren't philosophical objections to the vision of 'your' protocol.
Exactly, you pointed out implementation details in young projects that are still under active development, so perfect stability is not expected. What is your view on the broader picture, the fundamental protocol and vision?