here we are!

-where the flow is easiest to happen?

-millions of devs: this is easy!

-it's like the tv.

-sharing stickers or drawings

-persistent storage for the spw parser doesn't work

-some scheme for specifying nodes & associating them w/some lifetime & events

-eg clicking on a title of a node "goes somewhere" but the title as the identity of a node
  isn't very coherent

-"a certain number of nodes allocated to a company and then some sort of mapping scheme
 to like _____ (billions?) such that when people visit factshift.com they can click into
 an ecosystem/ecology eg something specific to a company's ecology or its arc"



- wondering how a company might represent hype around their knowledge base
- seasonal orbs, events, interactions, flows


-backend generating parts of the parser?
-orbs useful for comms

-i also don't like the architecture of the simulation. i think it's fun bc bugs :) -spwashi

-make useful for at least two people to "manage spwashi content" (whatever that means)

- weekly publication rhythm with at least 7 combinations of a CSS, JS, and HTML file available for download as a complete webpage by an audience of semi-technical fans of artists
  + upload a zipfile to an ftp server once a week and announce the url
  - "this seems like it would be accessible to a publisher [...] webmaster"
  "go to factshift.com/example.html" when they remember it, save webpage as HTML, have assets for an offline version
  + publisher tools? a web tool for yourself to stage & publish & name those.
  - "i'm ok sending files person to person for a bit"

 -webserver would be a good idea 

 - I don't think the github.com/factshift/app.factshift.com codebase is architected well for the kinds of interactions its features imply, and I believe the surfaces that are relatively memorable or accessible can be polished into something more prepared for modular releases

 - ideally each build target would have an entirely static version of this application with route-specific awareness of server connectivity