Yeah, the website is a holdover from when we were pitching AI VCs a few months ago. We quickly determined that the whole system is now "Cancer Capital" (see the other front page HN thread) and have pivoted to just bootstrapping from a close syndicate of like minded individuals. We plan to update the website this month, sorry it's a bit behind.
In short, AI identities were just a happy accident that comes with the system/architecture. It's not tied to AI at all.
But if anyone is interested in talking about what we're doing more, happy to connect at hn@sepositus.com.
Alice registers `alice.dntls` and Bob registers `bob.dntls` on the DNTLS network. During the registration process, they generate PQ key pairs that are registered along with the name. Alice's and Bob's name are hashed before being stored on the network. Bob knows Alice's name, so he can perform the necessary hash computation to look up Alice's public key material on the network. Likewise, Alice can do the same for Bob.
Bob wants to send a file to Alice. Bob takes his name key and signs the document with it and sends it to Alice. Alice looks up Bob's public key material on the network and verifies the signature.
Bob now stands up a new website, but he only wants Alice to access it. He sets up a standard HTTP server but slightly modifies it to be "DNTLS native." He does this by requiring mTLS on incoming TLS connections. The connecting party must identify themselves with a signed certificate. Each name has what we call a "name record" that allows publishing arbitrary metadata signed by the name key. Bob publishes a standard "HTTP" record in his own name record that points to the IP address. Alice now goes to connect to Bob's website. She opens her "special" browser and types in bob's name. The special browser looks up Bob's name record, finds the published IP address, and attempts an mTLS connection. Bob's server is configured to _only_ allow connections from Alice. Since Alice signed her TLS connection with her own name, the connection is allowed, while every other is rejected.
Alice now wants to communicate with Bob's agent. Bob publishes a subname called `agent.bob.dntls`. In that subname's record he publishes an A2A packet that contains the information for connecting to his agent. But, like the website, the agent is listening on a TLS connection that rejects anyone except Alice. She uses an A2A tool to initiate a connection using her name key and is allowed to make a mutually secured connection to Bob's agent.
Bob wants to connect to a VM he purchased that runs the website. He configures SSH with his name key as one of the recognized users. His SSH connection simply leverages the name key to authenticate him to the machine. But he shares the machine with another person and wants to share a secret with them. So he creates a SOPS encrypted file with his name and this other person's names as the only recipients. They both securely access the secret using their respective name keys.
I'll leave it there, but hopefully that's descriptive enough.
The technical implementation aside, "what" prevents this from going down the exact same path as ICANN? E.g. how do we know next year the registration fees won't be 5x or certain registrations denied?
A good question. Unfortunately, all I can say is we have a solution that involves specific European countries, laws, and regulations. As I said in a previous comment, happy to share more outside of this venue, but not all details are 100% public at this point.
We're simply choosing to build in a small group of closely aligned individuals and organizations right now. Many will become the first participants in helping run the public network across the globe. The network will launch completely in the open, including open sourcing the code. People can choose to wait until then to make their decisions or if they are particularly interested they can reach out to me about joining earlier.
A solution built in isolation by a group who just publicly tried to ride the AI wave with it is not a promising set of signs, but I have no problem leaving it at that until all is public and hoping it regains trust then!
Your solution seems tangential to the problem brought evident here, with how ICANN and VeriSign are able between themselves, to turn 22,000 or so tangible name registrations into dust, without any retribution or refund. The funny thing is that DNS -- where these names actually reside -- is distributed, but it's not as federated as to prevent the kind of takeover. Worst case, a rogue state can declare their own root name servers with their own fork of all name records including 3LDs for `.name`, show the middle finger to the U.S. and call it a win -- except that real people in the U.S. or otherwise using DNS servers that don't hold the forked data -- will fail to connect to the services expected at those names as specified by the rogue state, and will instead connect somewhere else. Basically like two realities of links pointing different places in each universe. A multiverse of name resolution. Not great at all, except what if the rogue state is larger and thus more power-dominant than the U.S.? The U.S. can pretend they don't care, but they become ostracised through DNS, and that's not going to win favours with the users. In other words if 4 out of 5 people prefer x.y.z. points to my actually useful website except some scammy ad-ridden page, then whoever doesn't point x.y.z. to my website is going to lose users -- unless those behind the scammy x.y.z. alternative pledge to monetarily compensate for every disgruntled user.
Anyway, name resolution needs to be federated because ICANN is apparently compromised as far as doing the right thing goes. A single root model may not work anymore. Maybe blockchain can finally do some good...
Names are not able to be traded, so it's first come first serve. It's impossible to completely defeat name squatting, but you can make it less enticing. In the above case, Alice can "sell" her name to Bob on some aftermarket but the only way to do so is by transferring the cryptographic material. This is fraught with issues, especially considering once Bob has the keys he has no obligation to pay.
Names are valid for one year and range from $10/yr up like current domain names. Letting a name expire opens it back up to being registered again.
We have quite a few other "tools" in play behind the scenes that make name trading/squatting extremely impractical, but I won't go into those details here :)
Like I said, it's impossible to "defeat" it outright because the concept doesn't really lend itself to this sort of structure. If I buy a plaque with my name on it , therefore owning it, the only thing that could really keep me from selling it would be some centralized authority. Even then, black markets have existed for drugs for centuries.
> CVE-2026-64012: net/sched: sch_sfb: Replace direct dequeue call with peek and qdisc_dequeue_peeked.
You are right, its over.
On a more serious note. Yes and no. The kernel is secure. It is probably the most scrutinized piece of software in existence. LLMs will find things but most probably they just will help contributors fix bugs.
You would think after all those years of Linus rejecting code and calling it "garbage" like some petulant manchild, there would be no garbage in the kernel...
I never understood the issue with DNS-01. if you have a process that you trust to maintain a zone's TLS identity what is the big deal about letting it control a record in that zone?
We have a few subdomains for white labeling 3rd party SaaS where we do what is basically the AWS ACM equivalent and add a persistent record from a vendor.
With this setup, I don't have to grant 3rd parties DNS access.
I actually made a webhook that allows per hostname API keys to wrap dnsimple because they only had per zone keys and I didn't want each VM to have access to the entire zone. These challenges would have solved that by allowing the DNS record automation to pull record values from the VM instead of having the VMs push values.
I think someone told me dnsimple might have more granular keys now but I haven't checked. Iirc we have the same concern with external-dns at work (some things need subdomains on the TLD but we don't want to give external-dns access to the whole zone so we usually cname the TLD subdomain to a per environment zone external-dns is allowed to update). With this, we could have the same pull based setup that applies arbitrary rules to decide if a requested record should be created.
I think the main takeaway is allowing pull instead of push model
Could be achieved with cnames but it's an extra layer of indirection to deal with and doesn't fully solve the "semi trusted 3rd party" case
You could already do that by setting a _acme-challenge alias CNAME record, so you can point it to a domain that they control. It's a bit finnicky and the new setup definitely looks better for whitelabelling, but there are current workarounds; although it does still involve client DNS access, you can put it onto a zone that has no risks
Our current level of granularity allows you to give read or write access to a specific zone, but it does not go down to the level of giving read or write access to a specific RRset type yet, if that's what you're looking for.
You can even put it in a seperate zone (which I do) by using a CNAME for _acme-challenge.domain.tld.
I have it to a seperate subdomain, which is served by a seperate desec.io account, which is only used for this specific subdomain.
TIL, thanks! This makes dns challange automation more approachable for me. I always had an issue with API keys which scope can't be limited to TXT records. This seems to be a nice workaround
In fact, Json as a common language for human in visualization has been around for a while! The benefit of declarative grammar is that users can effective manipulate specs through UI (drag and drop, clicks).
Btw, Flint is intentionally designed to allow agent skip low-level params like scale, axe, zero, step size etc (which are extremely crucial for "GOOD-looking") and they are dynamically optimized by the compiler. So AI agents can have a easier time.
> Json as a common language for human in visualization has been around for a while
Plant, Mermaid, Graphviz are all declarative textual representations designed for human authoring, JSON is made for tools. Its not a criticism just a statement that if interop across agent and human was intended this is not the simplest option.
Yes, Chatto's core system does not use e2ee. This is by design; if there ever are e2ee features -- and chances are good they will, in some shape -- the encryption will be layered on top of that (encrypted message payloads and such.)
Yeah, there are definitely valid contexts for hosting chat like this. E2EE has the benefit of not needing to trust the host, which I personally like but I can see this being fine or even wanted for lots of cases.
Last time I checked podman compose was only a superficial docker compose equivalent. Also stuff like inotify seems to randomly break a lot on the podman side.
I'd love to be able to recommend people use podman but not having a good docker compose compatibility and missing inotify on volumes makes the DX just too problematic.
Podman has supported plugin compose (v2) for years now, and I believe that's the version I used before I switched to Quadlets, but I must have not needed Buildkit features back then because those are apparently still unsupported over v2.
Don't know about that. I did a ddg search "using docker compose (v2) plugin with podman" I do get some tutorials but they all are from 2026. This also aligns with my experience from late 2024 where you where typical advised to use `podman compose` or the compose script.
Here's the 2022 release announcement for Podman 4.1 claiming support for compose v2. Your distro may have been stuck with an older Podman version for much longer though.
I spent about a week last year trying to move from docker+compose plugin to a podman hosted variant. It has issues on multiple stages of the lifecycle as I mentioned in my original comment. Mac users lose fs events, a lot of compose.yml features are flaky (post start events), buggy (reset and import), or just not implemented (don't remember the exact features).
If you use podman and have no issues that is awesome but your use case is probably quite narrow, you are most probably on a non fedora based Linux and keep compose usage to a minimum.
Yes, for play-online titles for sure, but I think everything up to Xbox 360 / PS3 era has robust emulation and wide distribution of the whole library.
Obviously it's gotten harder over the years, but PS4 and PS5 jailbreaks do exist so that means there's a vector for dumping games that were only ever distributed digitally (at least ones released up to the point where the jailbreaks got patched, as the stores will refused to serve new content until you update your system).
There's a bit of a hit-or-miss situation for them, from what I can tell. I recently spent some time trying to figure out which MLB The Show titles worked for emulation, and somehow after the 2010 entry, all of the remaining PS3 ones have a notorious noticeable bug where the middle (from right behind the pitcher going all the way down to the center field fence) the field is covered with random fans or other "debris", for lack of a better world. As far as I can tell, it's been known for years (I think it's an instance of the general problem of Z-fighting), but either no one knows the exact solution, or the people working on the emulators have so many other things to work on that it's not a priority.
On the other hand, the fact that people have spent enough time to write down which entries have this bug and which don't (and potentially even which stadiums have it and don't in the entries that do have the bug, since it's apparently not consistent across them) does lead credence to the idea that the library is pretty widely distributed.
Definitely another case where Nintendo platforms benefit from everyone having a shared understanding of which are the marquee, must-work titles; like every Mario and Zelda and Pokemon game will emulate flawlessly and after that is the long tail playable-but-maybe-buggy ones.
Current-gen console jailbreaks may exist but are inaccessible to the vast majority of the public so I really doubt they will factor into any decisions made by Sony, Microsoft, etc.
Yes, fair, and that matters if the discussion is "I want to buy someone's physical copy of a game released a few months ago that they are finished with". Digital distribution with robust hardware security does in fact completely destroy that market, though notably Switch and Switch 2 physical games tend to keep their value, suggesting that maybe it has less to do with physical media itself and more than the second hand market follows the pricing set by the digital marketplace, and consumers know that Nintendo doesn't really do discounts, even years later.
All that said, I think my main argument with respect to emulation and root access was less about individuals having that access, and more that so long as someone gains that access even through extraordinary measures, the games can be dumped and distributed, at which point true ownership becomes possible (even if it takes a while for them to become playable on emulation or hacked hardware).
There is diminishing importance of ownership as time passes though because there is less and less desire to own such assets as they get older and newer titles come out.
There are exceptions to the rule, but I'd imagine less than 1% of the population cares about owning/emulating PS3 or even PS4 games at this point.
So yes, there is an eventual vector for "ownership" (though illicit, at least in this hypothetical) but I doubt that moves the needle much if at all.
What is the typical motivation to start using em-dashes?
Why go the extra way to have a slightly elongated dash when a normal one would just as well do the job?
I might be conpletely off here but I've never seen a situation where using a normal dash where a long one should be causes any sort of syntactic trouble.
It looks aesthetically nicer. It was also a bit of a signal that someone took pride in their work and so helped that way. It's a bit like whether your tradesperson cleans up after themselves. Technically sweeping up the dust after installing a kitchen cabinet doesn't actually mean anything for the quality of the kitchen cabinet installation, but in practice putting the effort into the presentation correlates with putting the effort into the actual work.
I understand the sentiment with the tradesman example. I would argue that there are a multitude of ways to care about or take pride in one's trade and emdashing the floor is just one of them.
I think people who care about correctness and also read a lot automatically see the difference and it seems (and is) technically incorrect to use a hyphen where an em dash belongs. That’s really it. Kind of like you wouldn’t just leave out the apostrophes in your writing even though in most contexts they are not strictly necessary for comprehension.
Leaving out apostrophes isn't the same though, is it? If you leave out apostrophes you have syntactic effects while a (sortof)dash is still sort of a dash?
Its not exactly the same, of course, but its pretty analogous. It’s a minor, technically incorrect change that doesnt change meaning or understandability most of the time. Ive left out a bunch of apostrophes in this paragraph and Im pretty sure nobody will have a hard time understanding any of it. Yet it would bug me to actually write like this.
I don't know how this works nowadays but when I got taught to write (the pencil and paper kind) and specifically when I got taught syntax, it was "if you want to introduce a clause that explains or expands upon something that precedes it, you draw a small horizontal line" no mention of special chars, Unicode or whatsoever. So why is it so special other than being authors fancy?
i mean why use punctuation or any capitals at all, why not just blast words out in a stream of consciousness so readers know how yr thinking why even bother with speeling things write
Just because you don't care to use the proper dash doesn't mean everyone else doesn't. People have different levels of caring about different details. For the sticklers, there's even a special code point for ellipsis, … rather than .... (Four being correct, as one is to end the sentence.) Personally I'll just skip — entirely unless I'm in a trolling mood, though “sometimes” the right quotes are worth using. Special characters are easy to type on a phone soft keyboard, taking a long press on the relevant key, or if you're using any other advanced input system, so they shouldn't really be considered to be the mark of LLM input.
The real trouble is that people doing engage with the substance of the post anymore, and just shallowly dismiss a post as being vibe written, as if that makes any points raised invalid. Anti-intellectualism's always been cool among a certain crowd. Shame to see it spread but ah well, the propaganda's working.
Cool project! I had mistral vibecode me something similar (split into two services and run via docker compose) just a few weeks ago! I still have dome nitpicks with the result, maybe I'll switch my stack over to your solution!
reply