Linking to Public Files

,
1

All Fission users have a webnative file system. Apps store user data in public and private namespaces in this filesystem.

Files stored in the public namespace are available on the web through a couple of types of links:

  • Public links always link to the latest version of a file
  • Archival links permanently link to one version of the file

Webnative can help you generate public and archival links when your app creates or modifies a file. You can also generate links to older versions of a file.

Try the Sharing Public Files demo to experiment with public links and the code for the demo to see how it works.

Public Links

Public links are easy to share and remember, and they always link to the latest version of a file.

All Fission users have a custom domain name. Public links use this custom domain name and /p/ to link to a user’s public files:

https://${username}.files.fission.name/p/${path_to_file}

For example, if the user fission wanted to link to a shared.txt in their public folder, the link would be:

https://fission.files.fission.name/p/shared.txt

Even if they edit that file multiple times, this link will always work. This is an easy way to share all sorts of things – including public TiddlyWiki sites, HTML pages, or a link to a PDF.

Archival Links

Archival links permanently link to one version of a file. These links are great when you need a permanent record of a file.

Each time webnative creates or modifies a file, a content identifier representing the current state of the user’s filesystem is created. You can think of this as an identifier for a snapshot of the filesystem. This identifier is called a root CID.

CID is short for content identifier. To learn more about content identifiers, check out the Proto School tutorial or come by and ask us more on Discord.

Archival links use the root CID, /p/ for “pretty path”, and the path to the file:

https://ipfs.runfission.com/ipfs/${rootCid}/p/${path_to_file}

If we were linking to shared.txt then each time you edited it, the root CID would change. Using an Archival Link you can be sure that you are sharing the exact file contents at the time you are sending it.

Versioned Links

Webnative keeps a history of each version of a file. You can use Versions to access older versions and create links to them.

Versioned links use a CID for the version of the file.

https://ipfs.runfission.com/ipfs/${version.cid}/userland

Note there is no “p” here. This is linking directly into the WNFS file system, skipping the metadata layer, and as such this is intended for developer use, and isn’t really user friendly. This is linking directly to a file version (which could also be an encrypted, private file), unlike Archival Links which capture the entire file path of the public tree, including metadata.

A Note About Permalinks

Permalink can mean a link to content that might change or a permanent link to content. Webnative gives you the option to use public links or archival links, depending on your needs.

Public links are great for linking to dynamic content. Archival links are useful when you need to guarantee that the content has not and will not change.

7 Likes
2

Looks good! :+1:

Hopefully we’ll have https://${username}.fission.name/${path_to_file} in the future which should make public links a bit easier.

4 Likes
3

There’s another kind of link: A direct link to a file/folder via CID. You can get this CID in drive for public files via right-click “Copy CID”.

Drive does this by translating a relative archival link into an ‘absolute’ archival link:

const rootCid = await fs.root.put()
// We start off with some link like this:
const archivalLink = `/ipfs/${rootCid}/p/${path_to_file}`
// Then we use ipfs to get the direct CID:
const ipfs = await webnative.ipfs.get()
const { cid } = await ipfs.files.stat(`/ipfs/${rootCid}/p/${appPath}/`)
return `https://ipfs.runfission.com/ipfs/${cid.toBaseEncodedString()}`

Sometimes it’s useful to have the CID of a certain public file or folder, e.g. for using PATCH https://runfission.com/app/{App URL}/{New CID} .

4 Likes
4

That is excellent stuff. I have these things setup thanks to hints in discord. Suppose it will make it’s way to the API as early adopters are experimenting with it and share their learning. Hope to do that soon via IndyWiki.

It is also useful to get the CID for any file by Path in user’s drive. this is particularly useful, because paths in drive as on the web are never permanent. CIDs are.

5

Very pleased to see it working

It is empowering Edge Players and Full Edge Developers alike

for players it gives the ability to

  • share anything they create within the Fission Ecosystem on the web
  • keep it up to date
  • can be indexed by search engines

for Full Edge Developers

<user>.<fission app>.fission.app/p/<public path>

like

gyuri.indywiki.fission.app

Good for

  • viral onboarding,
  • self-propelled, user controlled, analytics and
  • out of the box customer tech
    opening player 2 app provider communication channels
    and allow players to join instant communities around a Fission/IndieHub powered apps
6

I don’t think we’ll do app specific subdomains — makes more sense to let app devs / users pick totally custom domains.

So, this might mean adding IndyWiki.app as a default app domain and handing out subdomains.