> 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?
Login to reply
Replies (6)
As for the neo4j password, would you share with me in which project you found that config please?
I assume it came from pubky-docker, which is intedended to be used as dev tooling only, so that hardcoded password makes sense.
Neither you nor your LLM understood that this is just dev tooling it seems, so I'm making it more explicit to avoid future confusion:
Thank you for moving Pubky forward with us.
GitHub
Add development-only warning to README by gcomte · Pull Request #27 · pubky/pubky-docker
Summary
Add a prominent README warning that this project is intended for local development and experimentation only
Clarify that it should not be ...
As for the neo4j password, would you share with me in which project you found that config please?
I assume it came from pubky-docker, which is intedended to be used as dev tooling only, so that hardcoded password makes sense.
Neither you nor your LLM understood that this is just dev tooling it seems, so I'm making it more explicit to avoid future confusion:
Thank you for moving Pubky forward with us.
GitHub
Add development-only warning to README by gcomte · Pull Request #27 · pubky/pubky-docker
Summary
Add a prominent README warning that this project is intended for local development and experimentation only
Clarify that it should not be ...
On the GCS one in particular, you're right that it's an implementation detail of one hosted deployment, not a protocol requirement.
But a sovereignty-branded platform whose flagship hosted deployment runs on Google Cloud is at minimum ironic.
"your keys, your content, your rules" running on the most surveillance-associated cloud on earth through your own implementation is smelly. People will react that way.
the configuration surface in the code is just a bucket name and a credential. No versioning policy, no lifecycle rules, no retention behavior besides your ToS and Privacy Policy which correlate to the off-putting find.
Transparency goes a long way, so you're on to something there imo.
The block explorer as indexer analogy works, but precisely *because* there are many independent block explorers (e.g. mempool.space, blockstream.info, your own self-hosted mempool instance, etc.), they're interchangeable, and they all read the same canonical chain.
If mempool.space censors or vanishes, you switch to another in seconds with zero loss.
The plurality out of the box is what makes "just use a third-party indexer" acceptable. Granted these tools also took time to develop and come about, so understood on the growing pain.
Encouraging a third-party sovereign indexer (not as a competitor) would be wise imo. Even if just to demonstrate it can and will be done. As a business entity, this is a brow raiser in and of itself. Especially paired with the opaque GCS bucket you run.
One I don't think we covered is the Nexus ships with a hardcoded default moderation key that can de-index posts, profiles, and files.
Configurable for self-hosters, sure, but pubky.app users are on Synonym's Nexus with Synonym's key and no opt-out or visibility.
How do you square a default centralized de-indexing authority with the censorship-resistance framing? Genuinely curious about the design intent here.
As for the broader picture, the products are very complex. You're already facing a difficult time with reconciling all of the moving pieces.
Being born of a for profit company raises some hairs (not to mention an absolutely off the rails CEO).
My guess is that profit eventually comes from whatever 'atomic economy' payment rails (Paykit, Blocktank, or something) come in the future. But from what I've heard from John there are no plans to even introduce a concept like lightning zaps, so no value for value is a really weak point. If this was purely a freedom tech offering, I wouldn't expect a business entity to need to be involved or for V4V to even be a question, it should be an option out of the box.
Tether isn't a great conception. Purely my opinion. But you asked. Sure, there are red hat companies that legitimately build on and fund open protocols. but what's tether's and synonym's real concern? Freedom or profit?