Direct linking to content by CID

[cdata]

It would be nice to be able to link directly to a CID from Subtext. There are a few reasons why one might want to do this, but perhaps the most relevant one to Subtext is to enable a user to capture a "permalink" to a piece of content.

Note that when linking to a CID directly, peer key / pet name is no longer needed to resolve to the content ID. So, it's possible to imagine linking by CID as a stand-alone link (with trade-offs at the margins).

Some ideas for what this could look like:

• A stand-alone link type with some distinguishing sigil. Ex: %bafyrei...
• A specialization of a slashlink. Ex: /cid:bafyrei...
• Support for ipfs:// hyperlinks. Ex: ipfs://bafyrei...

[gordonbrander]

I lean toward ipfs:// support. One of the design decisions we made for Subtext is to support pasting in bare links for common protocols (http and https, basically). Given we're building Noosphere on IPFS, we should probably support pasting in ipfs:// links.

[jackyzha0]

One really interesting example is how more experimental TfT apps like notation.app don't even use explicit links but rather rely on doing a full-text search for the direct text instead. This could be made potentially global (?) using CIDs

[gordonbrander]

...but rather rely on doing a full-text search for the direct text instead.

As an aside, this is more or less how we plan to use [[wikilinks]], albeit with a subtle difference for security reasons. Within Subconscious, the text within a wikilink will be normalized into a slug for a note. Visiting this note will display your own note and backlinks, plus a rollup of related content from people you follow. So links are an always unambiguous pointer to one thing, but that one thing may display a rollup of fuzzily related content.

[cdata]

I lean toward ipfs:// support.

The one thing to bear in mind with this approach and the distinguishing sigil approach is that if given the option to copy an "updating" link to content vs. a "permanent" link to content, the kind of link the user gets will be different for each choice.

[bmann]

ipfs:// or ipns:// links :)

Which also (could) take care of having an updating link as @cdata says.

I'd actually love to align on terminology. It has been a challenge for us to explain this consistently. eg. an "archive" link would contain a CID somewhere in the path. a "permanent" link (that always gets the newest version) would be an IPNS or DNS style link.

[cdata]

Yah, it's tricky to talk about this at times because we don't have a shorthand other than what we have borrowed from the hypertext web (permalink). I would welcome guidance from anyone who has spent time considering what to call these things.

In Subtext, we have slashlinks, which we think of as "updating" addresses through the Noosphere graph. A basic slashlink is /foo, which is implicitly "based" on the sphere the content is associated with. A slashlink pointing to Gordon's content looks like: @gordon/foo; in this case, /foo is based on Gordon's sphere. In either case, linking to /foo will yield updated content over time.

We may support ipns:// as an option for "updating" addresses, but we will probably avoid relying on it exclusively for two reasons:

1. IPNS names are 1:1 associated with IPFS nodes, which is incoherent with our architecture
   • I vaguely understand that this may no longer be true, but I haven't been following the space closely enough to know how it has changed - does anyone know more?
2. IPNS is a system that is somewhat out of our control, and has certain latency characteristics that we would have to grapple with. By using our own system for mutable pointers, we have more agency to massage the associated latency to suit our UX

[bburns]

I'd actually love to align on terminology. It has been a challenge for us to explain this consistently. eg. an "archive" link would contain a CID somewhere in the path. a "permanent" link (that always gets the newest version) would be an IPNS or DNS style link.

Maybe a "live" link could always get the newest version, a "static" link could point to a fixed version ?