@jens more precisely i guess the distinction really is whether you view the "userpart" or "localpart" as something different than a resource

like imagine if https://trwnh@mastodon.social identified not "HTTP Basic Authentication", but instead identified "the user `trwnh` on the host `mastodon.social` as accessed over HTTPS"

@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 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.

@jens right, but when you say you discarded that "actors are resources", then what does this imply? i took it in the same sense as a URI, which is to say that actors need to be identified in a different way than resources. hence me talking about `user@host` instead of `host/user`

if you have the time to get into that discussion, that is -- i'm okay with you coming back around to this whenever you feel up to it!

@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 ... 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.

@jens >identifiers of sorts

ids can be locations or names, generally; although locations are *also* names in a roundabout way. by my understanding, this is why semweb people use http: or https: in rdf statements -- they want to make statements about things, and they also want to ideally be able to use the Web to get more statements about that thing. given a choice between "name" and "name that can be looked up", they choose the latter.

@jens which is why i propose / am toying with "RNS" as a generic, scheme-independent way to look up resources

@jens ah, i think i get what you're saying -- is it that you separate "protocol" from "thing shared over protocol"?

if so, then i weakly disagree, at least insofar as we currently use the protocol to confer some level of identity to the Thing

one thing that came about in a subthread is the idea of further separating "resources" from "identifiers", in what i interpret as similar to the distinction between a "resource" and a "resource descriptor"

for example, the concept of a "user" as something other than a "resource", but still living on a "host" machine.

something like xmpp lets you identify xmpp://a@trwnh.com while something like http(s) instead uses the userpart for HTTP Basic Authentication

i guess the distinction really is whether you view the "userpart" or "localpart" as something different than a resource

like imagine if https://trwnh@mastodon.social identified not "HTTP Basic Authentication", but instead identified "the user `trwnh` on the host `mastodon.social` as accessed over HTTPS"

if HTTP(S) allowed it, you could directly type your handle into a web browser and get back some kind of representation, like a descriptor document with details about that user

at least with URIs, when identifying resources, identifiers generally can be categorized as either "names" or "locations"

but "locations" are actually just "names but with a specific way to look them up"

so i guess you can think of the "RNS" (resource name system) as a way to look up information about resources independent of the protocol used to access them

part of the reason we can't just use host-based identifiers directly is that hosts can serve different resources via different protocols

@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...

so https://host/thing is not the same as http://host/thing -- at best, the http redirects to https

another interesting tangent is that per RFC 4501 https://www.rfc-editor.org/rfc/rfc4501 you can refer to dns://1.1.1.1/trwnh.com as "what Cloudflare DNS returns when queried for the name `trwnh.com`"

but there's no way to authoritatively refer to "thing on host" without specifying an access method and protocol, which is to say that there's no way to know ahead-of-time that //host/thing is the same thing across.

@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 ... 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 ... 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 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...

@jens i thought TLS had nothing to do with IP, and the TLS cert just asserts that you are contacting a certain name (as vouched for by other entities who have their own certs)

so DNS (secured by DNSSEC let's say) gives you a claim that 8.8.8.8 is dns.google

and then TLS gives you a claim that you are handshaking with dns.google

is this wrong?

@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...