so, the currently discussed New Authentication Flow RFC proposes in its appendix about Containers that NFS containers are
mapping to the serialised version of either XOR-Address in the network
The XOR-Address should point to another container following the same convention as its parents or to a serialised file struct as described before.
Nowhere is that this data at the address must continue to be SD-Data, it could very well also be a serialised File-Struct as ImmutableData. However, that would mean any change to a file (even its name) would have to create a new ImmutableData in the system and link it anew in the surrounding Container. We haven't decided yet whether we'd like to favor SD-Data or ImmutableData for this in NFS.
However, if you wanted to share a permanent URI to that specific version, you could do that easily by just storing it as a ImmutableData. That would never change or be removed from the network. But that might not be what you want either.
Taking the example of the favorites from before, if you'd store a permanent URI (or, for that matter, you could also store the serialised data yourself and not need the URI nor an ImmutableData yourself), you'd never "know" about updates to it. In these cases a DNS-based "URL" is probably more useful, even if they sometimes go dead. That said, a browser could easily, for every page you are on, offer to store the retrieved field-struct. But then the internal links are most-likely still going to point to DNS-lookup locations so ... It might not render when they break. Or you'd have to replace all those links (including in all CSS and such) with similar serialised-file-structs.
That's entire possible though. So we could additionally have a
safe:data-struct:BASE64(serialised(FileStruct)) that the browser could undertand. It will be much bigger than all other proposed URLs though as it would contain the entire content...
Coming back out of the rabbit hole. I think we should make a clear distinction between what is a permanent link (address to an ImmutableData) and a mutating link (address to a SD) and the system might not provide both without having to do further network puts. However, this can still all very easily be done within an NFS layer.
I beg to differ. I do believe you can write a perfectly acceptable RFC about this. There is no need to understand all the underlying parts, you can really just describe the motivation, the API and URL-format and the expectation of what should happen (even from a higher level view) when that is called. Like: "we should add another NFS api call to allow creation of URLs for sharing like
getPublicLink(fileName: String, permanent: bool) -> Future<String>, which returns a URI of" ... yadaya.
Once proposed and in discussion, if there are any technical reasons to change things or the underlying network can't support certain things - I think I said it clearly enough, that this entirely possible - it can be changed. But with a formal RFC the team, especially the people working on the lower parts, have a much better idea what is proposed and can give their input. And once they agreed on it we could make that happen, or even leave it to community members, who'd like to get more familiar with the code base (I'm happy to mentor this)!