subconsciousnetwork / subtext

Markup for note taking
Apache License 2.0
274 stars 20 forks source link

Direct linking to content by CID #36

Open cdata opened 2 years ago

cdata commented 2 years ago

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:

gordonbrander commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

...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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 ?