Move state out of the URL

[icidasset]

And use the shared worker instead, or some other decentralised mechanism. Reason for this is that the UCANs and read keys in the URL can be too long.

[bmann]

I looked it up, and in practice the limit is ~2000 characters for broad compatibility https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers#417184

If we’re getting that message from go-ipfs we can look up what that number is / where the 414 is coming from.

[expede]

Reason for this is that the UCANs and read keys in the URL can be too long.

Not sure if this helps, but if this is from large proof chains, you can change UCAN proofs to CIDs today (though now you have to make sure that the proofs are available, so inline is best, or just for the transmission of a long-lived UCAN)

...Technically you can put the whole thing in a CID and the server can also grab it over IPFS, but that's a lot of indirection at the top level; better in the proofs since we can cache them

[expede]

I looked it up, and in practice the limit is ~2000 characters for broad compatibility https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers#417184

[The referenced Stack Overflow 👇 ]

(Note: this is a quote from an article written in 2006, but in 2015 IE's declining usage means that longer URLs do work for the majority. However, IE still has the limitation...)

2006 would make that IE 7 😛 Sounds like some truncation back 5 years ago or so as well.

Most modern browsers (i.e. the ones we support) tend to have an 4kb limit. I can't remember where we found that reference, but Daniel & I tested that in Safari, FF, and Chrome last year. Totally possible that this has changed, but I'd say more likely that some of our UCANs get very nested, so we need to handle this in any case.

[bmann]

Looking at the address bar screenshot fragment from Bread, it looks like some new user redirect / creation query string? We should be able to repeatedly get this result, rosano mentioned it as well. 414s should definitely get logged, can we see them in Sentry?

[expede]

I don't see anything server side. It's possible that it got reported as a 500, or that the 414 is from the browser directly.

If this is for passing data between tabs, the other way that we can potentially fix this is by using hash parameters rather than query params. IIRC they don't get sent to the server (they're kept client side)

[icidasset]

it looks like some new user redirect / creation query string? We should be able to repeatedly get this result, rosano mentioned it as well.

Nothing new there, query params were always used in that way after lobby auth (no changes lately either, except the ones coming up soon). Only the user themselves can replicate it, depends mainly on their UCAN chain (ie. the distance between the device they created their account on and the linked device, could be a single UCAN or 10 nested UCANs).

we can potentially fix this is by using hash parameters rather than query params

I wouldn't use hash parameters, that would interfere with the user's app routing. The url we redirect back to could have query params as well, but we combine those with the ones from the lobby. Which you can do query params, not with the hash/fragment. Mainly the browser allows you to do that with query params, not the hash, every user needs to bring their own hash/fragment parser.

UCAN proof CIDs sound like a viable option, will look into that 👍

[expede]

UCAN proof CIDs sound like a viable option, will look into that 👍

The one caveat is that you need to make sure that the proofs can resolve, or else the UCAN (and all of its children) are useless. The best direction I can give here is to make as much of the UCAN explicit/inline as possible, and use Merkle compression (CIDs) as close to making a server request as possible.

For the case of passing around query params, using IPFS directly actually seems like an interesting solution: save the UCAN locally to the node, stick the CID in the query param, and resolve it on the other tab/browser/device. If it's huge, compress that again in the proofs per request to the server, but keep the whole thing around in case you need to make child UCANs (which ideally are all inlined until you make a request)

[expede]

Actually, the more I think about this, the more I kind of want to remove the Merkle compression from the UCAN spec, and only allow it on the server at the topmost level (resolve everything underneath). Even a deeply nested UCAN will be at most a couple IPFS blocks.

[icidasset]

Actually, the more I think about this, the more I kind of want to remove the Merkle compression from the UCAN spec, and only allow it on the server at the topmost level (resolve everything underneath). Even a deeply nested UCAN will be at most a couple IPFS blocks.

Sounds reasonable 👍 I'll do a talk post about this later. There's some stuff we need to figure out here regarding working offline, among other things.