The current UX allows the user to click away from the Register screen once they have clicked "Register." They should not be able to do that! Once "Register" is clicked, it can take up to a full second or two for user registration and file system bootstrapping to complete. During that time, the interface needs to be "locked" such that the user can't navigate away. For instance, if there is an error during registration, if the user has closed the modal, they will not see the error message.

Some ideas:

• hide the "x" for the modal once "Register" is clicked
• show a spinner in the middle of the screen and dim the rest of the screen until registration completes

As discussed, we should make a separate org.

Whenever we open a pull request, it would be nice to have the GitHub publish action publish to a staging environment so that we can QA/preview it.

The fission drive application has a working implementation we can look at.

NOTE: This will be a last-PR-wins solution. The most recent PR to receive a push will be the PR on the staging server... unless you re-run the action on a PR you want to "claim" staging.

In my in person testing (primarily on mobile), people will click on links in the About Block rather than try the app.

Suggest rewriting the About block to describe what this demo does, and either including a “Connect” button or directing people to click Connect to get started.

Links to dev content can be moved to an actual About page.

We need to copy the new README over to the other WATs:

• webnative-app-template-react
• walletauth
• walletauth-react

Users of apps created with this template should be able to export a recovery kit that can be used to recover their account in the case that all linked devices are logged out or unrecoverable.

Tasks

• Get Webnative refactor tested, approved and merged
  • oddsdk/ts-odd#432
• Upgrade to Webnative 0.35
• Add recovery kit
• Determine boundary between WAT and webnative for recovery pieces (some initial thoughts)
• Add filesystem recovery
• Add username support for filesystem recovery

This might be better transferred to webnative but logging here because this template has a few key points where we init a filesystem and it takes quite a while.

It would be good to be able to have instrumentation that traces an init filesystem request all the way through including timings so we know what parts are slow.

When apps get loaded on arbitrary gateways — EG gateway.com/ipfs/APPHASH or gateway.com/ipns/APPNAME.fission.app— then an app will break and/or at least visually break when CSS and other styling assets don’t load.

The template should work out of the box to build with relative links, so that it can be loaded in any IPFS context.

We run a relative links filter as part of building @fission-suite/landing-page that may be helpful to look at.

Investigate how to use our stack to make the template extremely theme-able.

Motivation

We want people to use this template to build stuff. So we should do our best to publicize it.

Finish Line

• Punchy, short overview video of using the template to build an app? Or walking through it?

Check out this video for an example of short and punchy overview (100k+ views!!

The success and error notifications have nice thin icons, but we don't have icons like these for info and warning notifications. Let's add some notifications to fill out our notifications system.

Should probably include info about the current account plus access to a recovery kit download link.

UI question from @bgins - does this justify putting the hamburger menu back in?

UnoCSS offers a default preset, which provides a common
superset of the popular utilities-first frameworks Tailwind CSS, Windi CSS, Bootstrap, Tachyons, etc.

This means that no matter what framework a dev is familiar with, they can use uno and feel familiar.

As you are also using daisy I think this is worth considering:
https://github.com/kidonng/unocss-preset-daisy

The default app functionality is the ability to upload small binary files like pictures. The user should be able to upload files ( upload limit 5MB? ) using the default UI of the app.

WalletAuth flows will be different from flows where a user selects a username. Let's investigate how these flows would work in this app template.

Would be great to be able to scan a QR code displayed on a mobile device's screen with a desktop browser.

Developers need to be able to quickly create Webnative-based applications using a full-featured app template, particularly for the hackathon use case.

Milestone 0.3

Milestone 0.3 is the default milestone for new issues.

• App-owned user accounts
  • Move app-to-app auth delegation to webnative
• shared private data
  • blocked on changes inbound from rs-winfs integration

Milestone 0.2

Tasks

• #57
• #8
• #29
• #9
• #13
• #15
• #47
• #59
• #58

Dependencies:

• Data root missing when linking a second device
• Add username scheme and hashing support

Tasks:

• #4

Previous milestones

Milestone 0.1

Milestone 0.1 is now complete.

Whenever the servers can't be reached, we should let the user know things are offline.

Should we implement some sort of "extra explanations" mode for developers kicking the tires of the app template that goes into more depth.

We should have relative paths for all imported styles/assets so the various app templates are viewable on IPFS

SvelteKit has started to stabilize as it enters its release candidate phase.

Let's upgrade this template app to the latest beta version, which should experience minimal breaking changes going forward to SvelteKit v1.0.0.

Deployed demo links from the README are broken for Netlify (stopped deploying) and Cloudflare (got deleted).
It's a permissions/accounts thing. I was trying to do the right thing with a company-level account instead of doing the quick-and-dirty with a personal account and they are making it hard to do the right thing.

The UI for the homepage was assembled quickly without a design spec. It could definitely be improved.

A user sees two different views of the homepage. Before they register, they see an unauthed view

After they register they see an authed view

The About section is displayed in both cases, but the Account and Photo Gallery Demo sections are only displayed when authed.

@depatchedmode could you suggest some improvements for this page?

We should support static deployment platforms and show some examples that can immediately be forked / deployed.

I’ll list a couple but we should probably just ask different people to PR different providers. eG @bmann can do the Heroku version

We already support netlify, we should definitely consider IPFS-based providers as a deployment target

TODOs:

• Cloudflare Pages
• Vercel

Maybe in the future:

• Fleek
• Render
• Railway

Fission server (for dnslink) combined with Web3storage or Infura might be interesting to look at.

Motivation

The purpose of this application is to provide a starting point for developers to build applications with WebNative. Additionally, they will need to learn about some of the WebNative concepts in order to build the application. We need to have a comprehensive README that walks developers through the template application's features and highlights key WebNative concepts.

Finish Line

• Overview / header: a nice header and summary statement. One-liner describing what it is.
• Screenshot showing off the UI?
• Getting Started: should walk the developer through cloning, getting it running, and customizing the application to their needs, including renaming the appropriate things
  • Requirements: Minimum node version, etc
• Add disclaimer that the WAT is currently experimental and should not be used for production apps.

Once a user has uploaded some files as private data in the app, they should be able to share these files with other people, on a per-file basis.

Add WNFS support to provide storage.

As a developer, I would love to be able to enable a "debug" flag that enables a related debug UI component in my app that provides some insight into the internal state of the app, in particular the webnative state.

This view would be a spiritual successor of the django debug toolbar:

https://github.com/jazzband/django-debug-toolbar

As part of this, I suspect the best approach would be to provide this as a svelte component that takes a prop "debug=false" by default, and if the debug prop is false the component is a no-op. If debug is true it provides a UI that lets the developer inspect the wn object and various useful things like current user details / session state.

Once we update to the massively refactored Webnative,
the README and the Fission Guide will need to be updated to explain the new APIs.

In order to be as friendly to developers as possible, we should take what we have in 0.1 and make sure the code is organized well and re-factored so that all concerns are as separate and clear as possible.

When deployed, will show the standard providers default 404 page.

Make a 404 page, which can likely also link to Discord, docs, and other resources.

Also: make an ipfs-404.html static page as well, which will "just work" on IPFS hosts.

This is a followup to #38

We want input fields to have a white border in dark mode:

This is the current state, a darker grey:

(when released)

Motivation

In production apps, you shouldn't spew debug messages into the console. And yet, they're useful when developing or testing on staging.

Finish Line

• Set up an environment variable facility for stage
• Conditionally enable debugging when stage is production
• Document how to set environment variables

The social preview at https://webnative.netlify.app does not currently unfurl to app information and the social preview image. It can be inspected at https://www.opengraph.xyz/url/https%3A%2F%2Fwebnative.netlify.app%2F.

I think the issue might be in the dynamic way we fill in the meta tags. It may be that social media platforms do not execute the necessary JavaScript to populate the tags. They do appear to render fine in a webpage and can be inspected there.

Maybe there is a SvelteKit config that could help us with this? Another alternative would be hard-coding the values into app.html, but it would be nice to find a better way.

Motivation

We want this application to have good UX and suggest to developers the UX they should implement for their end-users. To that end, we want good error messages when they are needed.

Finish Line

• When the user has an unsupported browser or lack of certificate (InsecureContext or UnsupportedBrowser) we should display a helpful message to the user.

We need a default layout for the fs, primarily to suggest best practices to the developer.

Strawman:

/<root>
   /public
   /private

Where:

1. public is unencrypted
2. private is encrypted for the user only

In Customize Your App, the filenames are no longer valid as indicated below:

They should be:
+page.svelte and +layout.svelte respectively.

Motivation

We want developers to be able to learn about WebNative apps by using this template. An important component of that learning is well-structured, well-commented code.

Finish Line

• Go through all the files in the repo and add comments as you feel led

The username input and pairing code input fields need to be clicked into in order to input text. Should they auto-focus?

We should deploy the Webnative app template to Fission App Hosting. Seems like this is possible with some prerendering and a bit of configuration for serving from the HTTP Gateway.

See PR #66 for more details.

In Getting Started,

git clone [email protected]:fission-codes/webnative.git

should be

git clone [email protected]:fission-codes/webnative-app-template.git

Remove the "view on IPFS" link for private files / photos.

Maybe an "I" for info button with a short note "private files can only be viewed on other devices. Follow private file sharing (link to GitHub issue here)"

The app currently uses a favicon borrowed from boilerplate. Let's pick out a favicon that is more suited to the project.

We should be able to write a functional test that:

• runs 100 times ( arbitrary number )
• measures the full time end to end of how long it takes to initialize webnative
• measures discrete portions of this process
• reports on this breakdown

Motivation

The redirects file will soon be available in IPFS gateways.

In the meantime, this should also deploy seamlessly to modern static front ends like Netlify, Vercel (that's issue #9 for the full potential list over time).

Adding the redirects file will mean that people attempting to use those platforms will "just work".

Finish Line

• Add a _redirects file that will enable the template app to work on Cloudflare Pages, Netlify, Vercel, etc
• Document how to deploy in the README

The template should have pre-baked routes and views for authentication crud:

1. account creation
2. second device linking
3. connect

Motivation

We want people to use this template to build stuff. So we should do our best to publicize it.

Finish Line

• Blog post on the Fission blog

Summary

Problem

Users cannot recover their filesystem without a copy of their read key.

Impact

A user could irrevocably lose the private data they have stored in WNFS.

Solution

Create an account recovery kit that includes:

• Username (to look up their filesystem)
• Read key (to decrypt their filesytem root)

The user should be able to download a recovery kit for safe keeping and later upload it to recover their filesystem.

Most likely the recovery kit should be a text file for ease of creation and parsing.

The existing account recovery flow has some prior art: https://guide.fission.codes/accounts/account-signup/account-recovery. This flow uses a recovery kit as text file which might be a good starting point.

Motivation

We have made some fundamental changes to the way that WebNative works, including extending core components. All of those changes / options should be reflected in the Guide.

Finish Line

NOTE: Some of these sections will be duplicated in the README (See #13) with a slightly different emphasis.

• Document initialization options
• Document authentication options (Lobby versus no Lobby)
• Document account linking: dependency injection options
  • It might be helpful to show an example, at least in pseudocode, of how these dependency injections work. @bgins mentioned that a possible example could be showing a "matched pair" of a delegateAccount and linkDevice functions being passed during account linking to demonstrate sending additional secrets. Nice opportunity to emphasize the fact that device linking occurs over a secure channel!