NodeBB-ActivityPub Bridge Test Instance

@trwnh No, no, Zot relies on names again. Really, let's not.

Rotating keys, ah... that leads down a new rabbit hole for which it really is too late.

It's doable, suffice to say!

@trwnh No, I'm basically picking random identifiers here, for some definition of random

There's a whole lot of stuff hanging off of that, but the TL;DR is that a random identifier and a signature by the owner is good enough.

It can't prevent a collision, but it can ensure that my foo and your foo are different. Arguably the full identifier then are the tuples (foo, me, sig) and (foo, you, sig). But for most purposes except validation, foo is fine.

@trwnh So how do you know you and I get the same keys for did:example:whatever?

It's the same problem again?

@trwnh The linkage to the IP comes via the sender address in the IP packet. Yes, that could be spoofed, which is yet another issue. I tried to leave that out

But in principle a cert's name could also be an IP address.

It doesn't really matter for my rant, because that's more about there not being any connection to the resource or its "owner" for lack of a better term.

@trwnh ... notion of starting with some kind of name, while intuitive to think about, actually has all kinds of problems that we've been trying to solve for a long time by layering solutions on top of each other, and we're still not talking about the thing that'd actually make a difference (signed resources) *and* that'd make all of these layers rather unnecessary.

I hope that makes sense? I feel like my train of thought might not have been too straight a line

@trwnh ... I mean your RNS could point you to machine A with a URL, and mine could point me to machine B with some tuple of IP and port (single purpose server only producing that resource), and we'd still be reaching the same resource.

The same, cryptographically certifiable, by the magic of copies.

So names are all well and good, but what we really need are identifiers. People love hashes for those, which for a bunch of reasons I like less, but let's go with that.

The point is that this...

@trwnh ... locator scheme. The resource itself has to contain the information to verify it. Which in crypto terms means a signature and an identifier of the entity signing it (which needs to be a public key or point to one).

At that point, two rather interesting things happen, namely a) the external name given to the resource via a URI/URL is irrelevant to the resource contents, and b) the location of the resource is irrelevant.

Which makes RNS or whatever a very optional thing. By which...

@trwnh and in all this, this is about reaching a service, not a resource; we can't know anything about whether a resource is reachable from all of this, or whether it is the resource we want to reach. All we have is yet another name (URL) that could point to anything.

Which is to say that some URL of https://example.com/my-fancy-stuff could simultaneously be a text file and an image to different clients.

So the only way to be sure that a resource is *what* it should be is independent of any naming or...

@trwnh ... is intended by the person who should be making claims about this name and IP address set being linked.

And this is after several decades of using a name to locator resolution system.

There are DNS records for saying more about an endpoint, such as saying that it can speak e.g. https with a particular cert. That finally provides some cryptographic linkage between the two claims (though it still doesn't say much about intent; at least an attacker would have to convince two parties).

@trwnh ... handful if them. Arguably better.

But that is for the certificate by which the IP address claims that it belongs to the name that DNSSEC provided. But there's no real cryptographic linkage here!

Because DNSSEC effectively only makes a statement about someone having associated a name with a set of IP addresses in one place, and TLS certs make a statement about someone having associated a name with an IP address in another place.

Nobody can verify that these claims are both what...

@trwnh ... DNS tries to use DNSSEC to bring some layer of security to name delegation, but it all hangs off a trust anchor in the root zone. Global sources of truth are rarely a good idea, historically speaking, but that's how DNS is built.

But once you've resolved a name with DNS, you then contact that IP address (a locator), and in a TLS handshake negotiate a new security session of sorts. You're trust anchor for the certificates here is not a single source of truth, but a selection of a...

@trwnh So this name resolution thing I think needs to die, and the sooner, the better. At least in the way these things work currently.

Hmm, where to start? The web, I guess. There's a reason that there are URLs and later that got changed to URIs, and it's because they wanted to have a identifier-to-locator resolution service of sorts, and that just never materialized.

Meanwhile, DNS is full of hacks to make naming things *safe*, and to make it perform halfway. The key thing here is that...

@trwnh ... layers in some way, both for transport and access control reasons.

What you share in such a resource is sufficiently unimportant to the shape of those layers that I don't deeply care about it.

But I do think an AP like thing could be done on top, sure.

@trwnh The point is, you can build something on top where some resources say something about actors, and others say other things, and they can all be linked in an RDF-y way.

It's the underneath I'm more concerned with: you have a reason to communicate, and that reason is represented by some identifier which represents a resource. You can read and write from/to the resource, and so can anyone who shares in the group that forms around this resource.

That needs to be managed at protocol...

@trwnh So this very much is a resource oriented view. You can have resources that express something about actors, sure.

But at the protocol level, that isn't particularly useful. Here you need identifiers of sorts, and most likely cryptographic ones (i.e. public keys) that you can do access control stuff with.

The reason it's group oriented is, to loosely quote @dentangle , that one-to-one communications is a special case of group comms where the group happens to consist of only two parties.

@trwnh You're thinking in locators, not resources.

A resource is the thing the locator points to, and a locator encodes location, i.e. access methods are implied.

I'm talking about the thing that's being pointed at. It must have an identifier, but has no need for a locator, because it doesn't need to have any specific location.

You can build identifier triples for RDF, if you like. In parts it treats locators as identifiers anyway.

@trwnh ...and that leads to a bunch of other things becoming necessary at some point.

Hmm. Maybe this is interesting to you?

Interpeer Architecture

Videos exploring Interpeer's architecture, in contrast to those of the Web, as well as alternative approaches being explored.

MakerTube (makertube.net)

@trwnh I wish I had the time to pick this conversation up properly, but today isn't the day.

But a similar line of reasoning has led me to start @interpeer - though I wasn't so much interested in AP at the time. The idea was to find a common human oriented set of layers.

Turns out, actors as resources was something I ended up discarding (TL;DR), or rather treating as a less important part. The main part is group communications *about* resources, which requires identifiers (of actors),...

... what next can you optimize? You can put the key exchange even further up front, which may speed up the QUIC handshake.

And that only leaves us with DNS as anything that comes earlier. In addition to IP addresses and transport choices, now folk wish to put keys into DNS as well.

Which may be fine with small Edwards keys. But several KiB of post quantum cryptography key won't fit into a DNS message, which is in practice bound by the size of a UDP datagram.

So what then - we can't do DNS...

... it's no longer enough to resolve names to IP addresses, you also have to resolve to choices of transport protocols.

With encrypted transports, you always have a key exchange to deal with, which can be slow.

The TLS issue is that you have a TCP handshake, which exchanges three packets. Once the TCP session is established, you have a TLS handshake, which is also three or more packets. QUIC adds key information from the start, so you only have one handshake that combines both purposes.

So...