Main idea

All functions/types/constants are stored in packages (and not in canvases)
- a package name can be used like a repo eg @darklang/homepage
- so no UserProgram types anymore, just builtins and packages

Implications

A “canvas”/”service” only has Handlers, DBs, and Secrets (not fns and types or constants), and one or more @darklang.io domains or custom domains

handlers map routes to functions
- can call any function (in any package) with the signature HttpRequest → HttpResponse
  - or maybe we allow a little bit of wiggle room to make that easier
  - or maybe the AI handles the wiggle room, creating functions like @darklang.package-server.api.packageHandler automatically
DBs can use any type in any package
Service templates could exist which bring in routes and DBs
Issues:
- if DBs are in canvases and code is in packages, how do we write code that uses DBs?
  - same for workers
  Idea for DB/workers/Secrets in a package world
- where do tests live? If only in packages,
- it seems natural to want to make a http handler out of a multiple functions (a middleware one and the one with the handler’s logic)

packages are immutable types/fns/constants
names point to specific hash
- eg @paul.stuff.do_v1 () is really 572faed-23dab395
updates create new versions
- eg @paul.stuff.do_v2 ()
- changing a lower level function may change it all the way up
  - @paul.blog.getPosts_v1 references @paul.blog.getAuthor_v0. If we create @paul.blog Our editor must create @paul.blog.getPosts_v2` when