Hardcoded Synonym relay nodes? Default 'admin' password for homeserver operators? Rofl.

GitHub

pubky-core/pubky-homeserver/src/data_directory/config.default.toml at main · pubky/pubky-core

An open protocol for per-public-key backends for censorship resistant web applications. - pubky/pubky-core

line 24: admin_password = "admin" line 34: dht_relay_nodes = ["https://pkarr.pubky.app", "https://pkarr.pubky.org"]

GitHub

pubky-core/pubky-homeserver/src/admin_server/auth_middleware.rs at main · pubky/pubky-core

An open protocol for per-public-key backends for censorship resistant web applications. - pubky/pubky-core

Users of pubky.app have zero access to any of this. They're on Synonym's homeserver, Synonym's config, Synonym's relay nodes. Self-hosters can change it, that is if they are aware. Every homeserver deployed with default config routes DHT traffic through Synonym-controlled servers. A sovereignty protocol with Synonym as the default DHT relay is a structural centralization point baked into the defaults. Again, happy to be wrong or mistaken here. Just easy to spot issues at first glance.

But wait there's more... Pubky Nexus is what makes content discoverable. Feeds, search, profiles — all run through it. Without Nexus, your content exists but nobody can find it.

GitHub

pubky-nexus/nexus-common/src/config/watcher.rs at main · pubky/pubky-nexus

The Nexus between Pubky homeservers and Pubky-App social features. - pubky/pubky-nexus

line 23: pub const DEFAULT_MODERATION_ID: &str = "uo7jgkykft4885n8cruizwy6khw71mnu5pq3ay9i8pw1ymcn85ko"; Whoever holds this key can tag any post, profile, or file and the Nexus watcher silently removes it from the index.

GitHub

pubky-nexus/nexus-watcher/src/events/moderation.rs at main · pubky/pubky-nexus

The Nexus between Pubky homeservers and Pubky-App social features. - pubky/pubky-nexus

lines 40-54 posts, user profiles, files, tags. All erasable from discovery. Your data survives on the homeserver. But if Synonym's Nexus can't find you, nobody else can either. pubky.app users are on Synonym's Nexus, with Synonym's moderation key, with no way to opt out. Self-hosters can override it, again, if they know to. "Censorship resistant."

Cloudflare binary is downloaded at runtime with no checksum for the Umbrel App. https://github.com/pubky/umbrel-app-store/blob/main/pubky-homeserver/docker-compose.yml line 117: wget -q -O /usr/local/bin/cloudflared "...github(dot)com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-$$ARCH" The Umbrel app downloads the Cloudflare binary from GitHub at container startup. No checksum. No pinned version. latest at runtime. If that release is ever compromised, every Umbrel Pubky node silently pulls it. A sovereignty protocol routing through Cloudflare, downloaded fresh on every deploy.

Neo4j social graph database ships with hardcoded password "12345678" lol

GitHub

pubky-docker/neo4j.env at main · pubky/pubky-docker

One click Pubky deployments. Contribute to pubky/pubky-docker development by creating an account on GitHub.

line 9: NEO4J_AUTH=neo4j/12345678 line 5 shows # NEO4J_PASSWORD=12345678 commented out as the "default" hint, and line 9 shows it actually hardcoded active as NEO4J_AUTH=neo4j/12345678. They knew the password was 12345678 and shipped it anyway. The comment on line 7 even warns: "If you change the auth params and you have already created the config files, will not take effect." So changing it after first run is non-trivial. Your entire social graph — every follow, post relationship, and connection — stored in Neo4j with a hardcoded default password. No warning. No enforcement to change it.

John Carvalho's own manifesto states: "Master keys are kept in cold storage, and access is delegated through revokable homeserver sessions, minimizing exposure and maximizing security." https://medium.com/pubky/pubky-the-next-web-3287b35408f1 Let's look at what the code actually does. The master key (secretKey + mnemonic) correctly goes to the OS Keychain. That part is true. But session tokens (the credentials that grant active access to your homeserver) tell a different story.

GitHub

pubky-ring/src/store/mmkv-storage.ts at main · pubky/pubky-ring

Contribute to pubky/pubky-ring development by creating an account on GitHub.

line 4: const storage = createMMKV(); No encryption key. Unencrypted storage.

GitHub

pubky-ring/src/store/index.ts at main · pubky/pubky-ring

Contribute to pubky/pubky-ring development by creating an account on GitHub.

line 45: whitelist: ['pubky', 'settings'], The pubky slice (which contains your sessions) is persisted to that unencrypted MMKV store.

GitHub

pubky-ring/src/store/slices/pubkysSlice.ts at main · pubky/pubky-ring

Contribute to pubky/pubky-ring development by creating an account on GitHub.

lines 73-84: addSession: (state, action) => { state.pubkys[pubky].sessions.push({ ...session, created_at: Date.now() }); } session_secret pushed directly into the unencrypted Redux store. Your master key is safe. Your session tokens (the active credentials that authenticate you to your homeserver) sit in plain unencrypted storage on your device. The migration file makes it explicit — this isn't an oversight. Migration version 6 deliberately migrates session_secret into persisted storage:

GitHub

pubky-ring/src/store/migrations/index.ts at main · pubky/pubky-ring

Contribute to pubky/pubky-ring development by creating an account on GitHub.

lines 81-90: // Add session_secret to all existing sessions sessions: pubky.sessions.map((session) => ({ ...session, session_secret: '', })) "Master keys are kept in cold storage, and access is delegated through revokable homeserver sessions, minimizing exposure and maximizing security." Right. Sure @John Carvalho Nostr doesn't have a session token layer to compromise. Your key signs events directly, via NIP-07 extensions or NIP-46 bunkers (how you *should be* using nostr) that never expose it to apps at all. Pubky adds a session delegation layer to protect the master key (a reasonable idea) but then stored those session tokens unencrypted. The mitigation introduces the vulnerability.

This @John Carvalho is seems to be a full of shit faggot. He can stuck his Pubky up his pufta arse.

All of your observations seem correct - users are aware (or at least I am). Iirc homeserver beta was rolled out a few months ago, but I think it's still private beta. Check back in a couple of months.

Bahaha you are doing some sort of retarded ai audit? Holy fuck this place is hilarious. Dude, just believe whatever you want i truly dont care if people this retarded never use pubky. You deserve your silly nostr life.

Have fun being stupid

That's your response? To facts pointed out in your code? Lol. Good luck man.

I'd fork your product and fix everything wrong with it, but I'd end up at nostr 😂

Bro this shit is just wrong and makes you look stupid to smart people and smart to absolute fukn troglodytes.

Should be a pretty simple response to clarify then. Calling people retards isn't really helping you.

You have no intention of learning; you just wanna find something ignorant you can dunk on, like we are in high school, like a little teenage asshole. If you are actually smart and take pride in yourself you will take this embarrassment to heart and come back when you actually know your ass from your elbow. You are not qualified to judge Pubky tech, which means you cant judge Nostr properly either.

Still waiting for you to point out which part is wrong lol.

All of it. Get a better ai to explain how.

Cause you can't? Lol. You told me to put cursor on it. 😂😂😂

npub1jxjzmmfxafzanf2kvnggrwqnd7jw8x6xrp7kggvpqdmkw0ldmv4suztxhc maybe you can help clarify since the CEO can't help but crashout

Are these easy configs to change?

That preaasumes every app must have cringe twitter-esque UX and discoverability. The best apps iirc will use local mesh to unlock value for existing meatspace communities. Your critique is on pointtl though. Putting the current beta implementation aside, is there anything that you like about the architecture?

not yet no.

Moving from one homeserver to homeservers per user (or uncle Jim) is huge. Although it seems like a logical decision to roll out on a single homeserver in order to build the very early basic UX around tagging etc. That's just an assumption though. I'm not involved and not even part of the open dev chat groups.

The supernova for me was understanding how PKARR works. There are a lot of docs are linked to at pubky.tech but I guest most people are gonna realise the proof of the pudding in the eating. Difficult to abstract prior.

Hablas más que un perico con diarrea, y dices menos, cabrón :)

Wtf happened you John? Signed by you, hope you are proud of your words.

his own dev conceded this needed improvement. 😂 John is going far. genuinely concerned and praying for the guy.

I grew up.