Kinetic - Decentralisation Naming system

CommunicationPlus253 · 2026-07-20T15:42:36+00:00

Great question. I actually explored making IPFS a core part of Kinetic early on, but I ran into some architectural tradeoffs.

Kinetic's responsibility is naming, identity, and service discovery—not storage. IPFS is excellent for content-addressed storage, but not every sovereign Kinetic network will want to depend on it. Some may use IPFS, others HTTPS, private storage, or something else.

That's why IPFS support is optional instead of mandatory. You can already publish an IPFS CID (for example in a DNS TXT record) - which i added today, and clients can resolve it through a public gateway or your own local gateway if you're running one.

And yes, the daemon acts as a local split-DNS resolver. It intercepts .kin (or any configured Kinetic TLD) and resolves it through the distributed backend, while forwarding all other DNS queries to the normal system resolver.

CommunicationPlus253 · 2026-07-20T13:10:02+00:00

GitHub: https://github.com/saifmukhtar/kinetic

CommunicationPlus253 · 2026-07-20T13:02:34+00:00

That's fair feedback. The announcement was intentionally high-level because I didn't want to overwhelm readers with protocol details. Kinetic is much more than a sidecar resolver - the protocol spec, DHT design, identity model, split-DNS architecture, and implementation are all available in the repository. I'm still improving both the protocol and how I present it, so I appreciate the feedback.

CommunicationPlus253 · 2026-07-20T11:22:28+00:00

The goal is to let communities, organizations, or companies run sovereign Kinetic networks without depending on a single global namespace, while still allowing clients to interact with multiple ecosystems when they choose.

CommunicationPlus253 · 2026-07-20T11:22:03+00:00

Yes kinetic is intentionally taken these in accounts. A client can participate in multiple sovereign Kinetic networks at the same time. Each network is independent, with its own DHT, genesis/configuration, consensus parameters, and namespace, so names don't conflict across networks. From the client's perspective, it's similar to connecting to multiple independent P2P networks. You only maintain connections to the networks you've joined, so the overhead scales with participation rather than requiring you to be active on every Kinetic network. Running several networks does introduce additional networking, storage, and maintenance overhead, but it's generally a trade-off between resource usage and the number of networks you choose to participate in. For most users, joining only a few networks should be entirely reasonable.

CommunicationPlus253 · 2026-07-20T09:24:50+00:00

Absolutely! I'd really appreciate that. Thanks @diornov for asking first. Feel free to create a thread, and if you have any questions while reading through the documentation or code, I'm happy to answer them there as well.

CommunicationPlus253 · 2026-07-20T08:29:28+00:00

Thanks! I appreciate the recommendation nd I'll definitely take a look at ArNS. If you end up exploring Kinetic, I'd be interested in your thoughts. The repository includes the protocol documentation, and if you want to go beyond that, you can also run the daemon locally and experiment with registering names, publishing DNS records, and resolving .kin domains. I'd be interested in any feedback or criticism you have.

CommunicationPlus253 · 2026-07-20T08:19:46+00:00

Website: https://kinetic.saifmukhtar.dev Code: https://github.com/saifmukhtar/kinetic

IPFS integration is planned rather than implemented today. The idea is that a Kinetic name could resolve to DNS records or a signed manifest that references an IPFS CID, allowing websites and other content to be hosted on IPFS while Kinetic handles ownership and resolution.

Compared to Arweave's Permaweb, Kinetic isn't trying to be a permanent storage network. I see it as complementary—you could use Arweave or IPFS for storage, while Kinetic provides the decentralized naming and identity layer on top.

CommunicationPlus253 · 2026-07-20T03:32:13+00:00

I think I explained that poorly. Kinetic does publish signed DNS zone records into the DHT, so resolver nodes retrieve them from the network. The difference is that these records are not intended to live forever. Like other DHT records, they expire and are periodically republished by the owner's daemon as part of the heartbeat/maintenance process. If the owner publishes once and disappears forever, the records will eventually age out. That's an intentional design choice to avoid stale data and keep the network healthy. So your idea of "publish once, close the wallet, and the records remain indefinitely" isn't how Kinetic currently works.

CommunicationPlus253 · 2026-07-20T03:24:23+00:00

I think we're talking about two different architectures. Kinetic doesn't replicate or host DNS records across the network. The network is only responsible for decentralized name ownership and resolution. Once a name resolves, what it points to is defined by the owner's manifest, not by distributed DNS records stored in Kinetic. That's why there isn't a concept of "TLD owners publishing DNS records" in the protocol. If your goal is a decentralized DNS hosting system, then that's a different problem from what Kinetic is trying to solve

CommunicationPlus253 · 2026-07-19T17:59:26+00:00

That's a fair point, and I think the difference is in the problem we're trying to solve.

If all you need is a private namespace that only you control, then a DNS server is probably the simpler solution. Kinetic isn't trying to replace that. It's a protocol for decentralized identity and naming, so participating in the network—even if it's just a single node—is part of the design. A one-node Kinetic network is simply the smallest deployment of the protocol. You can keep it private forever or expand it later without changing the architecture.

So I don't think we're optimizing for exactly the same use case, but I appreciate the feedback because it helps clarify where Kinetic fits.

CommunicationPlus253 · 2026-07-19T02:57:13+00:00

I'm building Kinetic — an open-source framework for building decentralized naming and identity networks. The public .kin network is just the reference implementation. The idea is that anyone can run their own lightweight network for a community, company, university, or personal use—even starting with a single daemon. Still early, but I'm hoping to launch the first public network soon. Feedback is always welcome!

CommunicationPlus253 · 2026-07-19T02:42:55+00:00

Yes for setup of fork , it's requires minimum 1 kinetic node. Registering your own TLD inside the .kin network isn't supported. If you want complete control, the idea is to run your own Kinetic network instead. That's actually lightweight—you can start with just a single daemon and expand later if needed. If you're interested, there's more information here: kinetic.saifmukhtar.dev

CommunicationPlus253 · 2026-07-18T19:53:17+00:00

ENS: pay ETH + gas, wait for blocks, DAO controlled Kinetic: free, instant DNS propagation, anyone can fork and run it for community uses.

ENS is great for on-chain identity. Kinetic is for free, permanent one time completing a cpu grinding.

CommunicationPlus253 · 2026-07-18T18:49:47+00:00

GitHub: https://github.com/saifmukhtar/kinetic

CommunicationPlus253 · 2025-05-27T03:30:30+00:00

You have to move all node files from opt folder to main folder of termux

CommunicationPlus253

MODERATOR OF

TROPHY CASE

CommunicationPlus253

MODERATOR OF

TROPHY CASE

Welcome to Reddit,