Napster with object-capabilities

[John Carlson]

I’m wondering what the **** I’m doing building a Napster for Classic VRML without anything better than bearer tokens.

I guess the alternative is Distributive Interactive Simulation.  But that means, probably, everyone is in the same simulation, or you have a lot of virtual machines on VPNs and you at least have to distribute UDP/IP addresses.   I have an Apache server running HTTPS.

[Alan Karp]

What's the problem with bearer tokens?  They are the better solution when the volume of requests are high.

If you want something that's more secure against token theft but don't want to go all the way to certificates, as in zcap-ld, you can look at OAuth Proof of Possession.

--------------
Alan Karp

On Tue, Aug 12, 2025 at 12:27 PM John Carlson <yott...@gmail.com> wrote:

I’m wondering what the **** I’m doing building a Napster for Classic VRML without anything better than bearer tokens.

I guess the alternative is Distributive Interactive Simulation.  But that means, probably, everyone is in the same simulation, or you have a lot of virtual machines on VPNs and you at least have to distribute UDP/IP addresses.   I have an Apache server running HTTPS.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAGC3UEk7DV5jgBCwjb6DW15t6R%3DpAoLndczy9Orp8k5X3DgeDA%40mail.gmail.com.

[John Carlson]

This looks good.  I probably won’t use headers, unless that is available with socket.io, but it looks like I could simulate headers.   The main problem I see is that socket.io has 3 selectable transports: Https polling, secure websockets, and webtransport.   I’m not sure the last works with older Apache servers.  I think I’m still on an old Centos server.

Here’s what I found so far:  

https://datatracker.ietf.org/doc/html/rfc9449

I know CyberTown Revival uses JWT and their architecture is similar.  Maybe they’ve solved PoP.

The other thing I worry about is we don’t have security between Apache and node.js yet, so server certificates are kind of fake.  I’m guessing this is fairly typical.  Sigh!  PoP gives me more confidence.

Ok!

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3tappsdjzb4dGxn83tVMdi5X7w1Bqk4sjqD_XCoh5ZpA%40mail.gmail.com.

[David Nicol]

On Tue, Aug 12, 2025 at 2:27 PM John Carlson <yott...@gmail.com> wrote:

 a Napster for Classic VRML

Is IPFS involved yet?

--

Nothing but net

[Jonathan S. Shapiro]

John:

Not sure what you're starting from, so some or all of this may be baked in:

A JWT as a bearer token is good, but you want to limit how much session state it carries. It's super helpful if:

• It includes the client IP address for which it is valid
• It is regularly refreshed, with refresh denied if requested from someplace that is NOT the valid client IP address
• It includes a nonce (64 bit or better) naming the server-side session ID. The nonce should change on refresh (which means sessions may have at most two active nonces, each with an expiration).
• It is signed, or better, encrypted.

That's probably all you need. The result is short enough that you can decrypt once and cache the resulting information on the server side with a timeout, so the encryption overheads aren't all that high.

After that we get into friendly fisticuffs about bearer tokens. Capabilities, in pure form, are bearer tokens. Possession is necessary and sufficient proof of authority yada yada. There's a lot of simplification on the server in that, but it isn't a particularly good approach to implementation because bearer tokens on the client are too hard to secure and too easy to steal. In short order you end up adopting some variation on token refresh in an effort to prevent bearer token theft, after which it isn't a bearer token anymore.

Which is a slippery slope. You end up in one of two places:

1. Only the very low levels of the protocol stack understand that it isn't a bearer token. Everything that is session aware treats the session nonce as the inbound capability index and treats that as a bearer identifier. Add access rights to the JWT and this is as close as you'll get to a capability design, or (and probably inevitably)
2. At some point some clever dev says "oh, this isn't really a bearer token, so I'll add something clever that is session dependent."

Arguments about access control, a major problem with (2) is that it defies device authentication. So if the fabric you are building needs to be able to authenticate and/or identify devices (e.g. IoT), step 2 constitutes a requirements violation. You can get devices to handle everything in (1) with relatively little work following initial introduction. Most of what you might be tempted to do in (2) requires more durable security state than you want the device to have. As with disk drives, it's prudent to assume they don't get erased on discard. :-)

Not sure how much of that's helpful, and don't want to rattle on without a clearer sense of what you are after.

Jonathan

[John Carlson]

No, I don’t know what IPFS is.

Apparently, my ideas are failing due to CORS with socket.io??? I can’t do search on client.

Either that, or there’s something with express.js/socket.io working with web clients and non-web clients.

I’ve tried cors options on socket creation.

The difference is the “app” parameter to createServer().   Take it out, and web fails, leave it in, and non-web clients fail.

I know I left details kind of rough.

Maybe socket.io is in the way.

John 

[John Carlson]

I’m fairly sure that socket.io will take care of some of the session stuff?  Like it keeps track of socket.id’s even when using http polling, I think.  A major thing I see currently is supporting both web-based clients and non-web-based clients.  At least I’m having trouble getting both operating at the same time.  I’ve tried configuring CORS.   At least what Google AI says; I’ll look to what socket.io documentation says.

I’m still using unencrypted http for prototyping, hopefully, I’ll do something with secure web sockets.

This might end up as just a demo app that I make a video from.   What I kind of want to do is write a docent app for curating VRML from 4000+ examples.  Or storing relevant links for a slide sharing app.

It’s a way of “streaming” curated URLs, but currently, I’m stuck on getting the client search (ambient authority) working at the same time as the web client.

I fully understand that I do not want arbitrary search clients attached to my socket.io server.

The plan in the longer term is for the web-client to provide the search client a capability, so the web client can confirm it made the search request from the search results, which will include the capability.   So the web client gives the search client the ability to populate a list of VRML URL results on the web client.

The main idea is to curate these examples:  

https://www.web3d.org/x3d/content/examples/X3dResources.html#Examples and make “tours.”

It’s a great resource, there’s just a lot of it.

Sigh!

John 

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QO84mhnaUoD4jJgiaQLO6zvSBxKinsx%3DkRjyUWkXHw2Pg%40mail.gmail.com.

[John Carlson]

Well, I got a basic client search engine working.  Now to add capabilities and encryption.

So the non-search client can select which gathering clients to send searches to.  Non-search clients will not receive the server search command, as search client engines will have gatherings under the parent gathering.  The search command will include a capability and a group in the hierarchical menu (probably all clients of the gathering will appear in the menu).  The search client engine will return the capability with search results.

So it seems like a typical capability file system that Jed Donnelley proposed to me, except that the search parameter allows for limited ambient authority (the client search engines limit themselves to certain folders).

I think I need to focus on creating peer to peer gatherings on top of socket.io.  Hmm

John

[David Nicol]

IPFS "InterPlanetary File System" is a file sharing scheme sort of similar to Torrent, in which large files are distributed and pieces fetched from participating nodes that have the file.

On Wed, Aug 13, 2025 at 2:43 PM John Carlson <yott...@gmail.com> wrote:

No, I don’t know what IPFS is.

--

Nothing but net

[John Carlson]

Does IPFS work in a browser?   My main target is either web browser (for viewing the file) Electron, eventually (for viewing).   I am merely downloading files once the search engines provide URLs, which might be local to the web server or remote.

[John Carlson]

I did notice something peculiar with my app, if a URL returned from search is the same as in another group, say the default groups, then the one in the default group is shown, not the search results.

[David Nicol]

I'm no IPFS expert; I'm just pointing out that IPFS is an available distributed file-sharing technology.

On Mon, Aug 18, 2025 at 10:38 PM John Carlson <yott...@gmail.com> wrote:

Does IPFS work in a browser? 

--

Nothing but net