New Website

[maximousblk]

Website

Design: figma.com/file/BfYs1TMPaEx8Mr9haEPE6H (incomplete)
Preview: figma.com/proto/BfYs1TMPaEx8Mr9haEPE6H

Stack

• NextJS
• Supabase Auth
• Docusaurus

UI

• Minimal
• Dark Theme
• Use MDX for rich-text content

Auth

• Email/Password (primary)
• GitHub
• GitLab
• Magic Link

The email is required for all the auth methods because it is used to link your account to all auth methods. the email will not be exposed in the api (or anywhere really).

Pages

Home

• Hero
  • Title: Nest
  • Sub: The immutable module registry for Deno
• Description
• Features
• Get started
• Standard modules

User

• Avatar
• Username
• Name
• tabs
  • Modules
  • settings
    • [ pending ]

X

• Search
• Featured modules
• All modules (default sort: updated)

Module

• Name
• Tabs
  • Code
    • Version selector
    • Link for the latest version
    • Nest URL breadcrumbs
    • Files
    • Link to raw (arweave) version
    • Link to type docs
    • Highlighted code
  • Insights
    • Full Name
    • Description
    • Downloads (chart for a week)
    • Dependencies (Maybe "dependents" too?)
    • Licence
    • Quality
  • Settings
    • [ pending ]

Blog

• Minimal MDX blog
• For detailed release notes and announcements

Post

• Title
• Date
• Read time
• Content
• Edit link

Orgs

• Hero with logo, name and description
• Link to their homepage
• Link to their GitHub/GitLab
• List of all modules

Routes

nest.land # home page
nest.land/u # redirect to current user's profile
nest.land/u/:user # user profile & list of modules
nest.land/u/:user/settings # user settings

nest.land/x # modules
nest.land/x/:user # redirect to /u/:user
nest.land/x/:user/:module # redirect to latest version
nest.land/x/:user/:module/:filepath # redirect to latest version
nest.land/x/:user/:module@:version # details for specific version
nest.land/x/:user/:module@:version/:filepath # filepath for specific version

nest.land/- # redirect to /x
nest.land/-/:module # vanity url for details for latest version (redirect)
nest.land/-/:module/:filepath # vanity url for filepath for latest version (redirect)
nest.land/-/:module@:version # vanity url for details for specific version
nest.land/-/:module@:version/:filepath # vanity url for filepath for specific version

nest.land/docs # homepage for docs
nest.land/docs/nest # website docs
nest.land/docs/eggs # eggs docs
nest.land/docs/cli # nest cli docs
nest.land/docs/api # api docs
nest.land/docs/terms # usage policies, etc.

nest.land/blog # latest posts and search
nest.land/blog/:slug # Blog post

orgs.land # info about the service
<org>.orgs.land # organisation profile and modules list
<org>.orgs.land/:module # details for latest version
<org>.orgs.land/:module/:filepath # filepath for latest version
<org>.orgs.land/:module@:version # details for specific version
<org>.orgs.land/:module@:version/:filepath # filepath for specific version

Notes

Why Next.js and not Vue/Nuxt or Svelte/Sapper?

1. Incremental Static Regeneration (IRS)
2. We use Vercel for most of our user-facing infrastructure and Vercel has native support for Next.js
3. We also depend on Vercel's sponsorship and as per the sponsorship conditions, we cannot use SSR (Nuxt, Sapper) and using client-side rendering greatly impacts performance (and obviously SEO).
4. Also, Next.js has "API Routes" features which can be used to create serverless functions to go alongside the website.

PS: Why Next.js is Great for egghead.io - Joel Hooks

Why Supabase Auth?

Because we are already using Supabase for our backend and it handles everything.

Why /x/:user/:module and not /x/:module?

People have to be able to publish a variants of an already existing module with the same name but under their account. Similar to how GitHub does it. you can have "forks" of an already existing project.

There are only so many sensibly short combinations of alpha numeric characters that make sense as a name.

It also helps with "name squatting" and "typo squatting" which have been an issue with npm in the recent past.

ref:

• Recent incident of typo squatting on npm
• strawpole for how to handle squatting on deno.land/x (leading answer: "delete the module even if a version is published (with no considerable content)")

Why is /-/:module a vanity address?

This address will be provided to good quality and trustable modules. So whenever you see a module on that address, you know it's good. To get a vanity URL, a module will have to meet certain criteria that ensures code quality and authenticity. The vanity address will be granted after a manual review.

Criterion (in discussion):

• Properly formated
• properly linted
• Properly documented
• Includes license file
• includes a lock file
• 90%+ test coverage

Authentication

• Primary login would be a email/password pair (paired with HCaptcha).
• Secondary options would be to use GitHub, GitLab or a "Magic Link" to login.

Emails are used to identify you if you use multiple login methods.

But what about GDPR?

GDPR doesn't restrict the collection of user info. The only thing restricted is the sharing of that info with third parties without the user's explicit consent.

Module Analytics

this will be moved to it's own rfc once we settle on a solution

Module import analytics may be the hardest part to implement correctly. We absolutely don't want someone to just do watch curl <Module URL> and fake the numbers.

Checking user agent for Deno won't work cuz you can do watch deno cache -r <Module URL>

So we need the analytics to be bound to the IP address of the user and have a cooldown before that IP can be counted as a real user. I'd suggest one or two days cuz you don't need to refresh your cache that often.

But with that approach, there is a problem of people abusing the CI/CD services as every instance has a separate IP. You could write a cron job to deno cache the URL every minute.

An obvious question arises here:

How does NPM and other registries do it? they got legit download metrics, right?

Nope. NPM themselves claim that the download counts are not accurate and having accurate analytics is hard.

tl;dr: they count every HTTP 200 request as a download.

Same for GitHub, PyPi and almost all kinds of registries. This is because they didn't need it to be accurate.

Now someone would ask,

how does YouTube count views? I tried some bots, they filter it out just fine.

Agreed. So does Google analytics or any analytics service for that matter. But the two products and distribution methods are fundamentally different.
They have the advantage of being on a website that can run javascript code on the browser to figure out if the client is a bot. an HTTP server has no such feature.

This is the whole request that is sent to the URL from Deno when caching or running a remote file:

> GET /-/eggs@1.0.0/mod.ts HTTP/1.1
> Accept: */*
> User-Agent: Deno/1.5.4
> Accept-Encoding: gzip, br
> Host: localhost

There can be no captcha, no cookie, no cursor tracking, nothing to differentiate a bot from a user. At this point I think we should look for another metric for deciding the payout.

misc

• Module authors can apply to manually verify a module. Only verified modules will be featured at the top of the "modules" page. "Verification" here means that we check if the module isn't malicious or a "not useful enough" module (looking at you isOdd()).

• Lazy load the lists only on user input i.e. when the client presses "Load more" (ref. design).