Forest @forestjohnson@pixie.town

@aynish was tempted to recommend looking at some of my projects to get a vanilla js boilerplate if you are interested... until I remembered how jank they were, evolved from a codebase that predates `fetch` , etc etc

@aynish react is fine, if you want to be snobby you could write it from scratch / vanilla js. But honestly as close to "default settings" react as you can get might be the easiest to get started with. For local first you just need serviceworker to cache the static assets (not sure how to set this up but hopefully there's just a switch to flip) and localstorage or indexeddb to store the data

@technomancy
What does ESR stand for ? Extended Support Release?

I think the "permacomputing movement" might be what you're looking for? But its still in its infancy.

Ultimately I don't think FSF matters, FSF is not useful, it doesn't really do anything. But Gnu, as much as I love to hate it, is very useful and matters a lot.

I think if you want such a change to take place, (fsf deposed and their cultural position assumed by a new org) it will require the creation/growth of a new thing that's genuinely useful in the same way gnu was.

I guess I mean the ideology only matters as far as it influences the design of the software / system. I don't think it really matters that much with the license says or what the "foundation" claims to stand for

I would worry about users "missing" each other and never being able to get a copy of whatever data from each other.

I would expect users would read silence as "this app doesn't work" or "no one likes me", not as.. *takes deep breath*...

> "oh, I must have missed that message because the senders client / senders friends clients were never connected at the same time as mine, and my client was never connected during the servers retention period after it was sent"

Ultimately I think the server retention period will have to be cranked really high to make the app usable and prevent missed messages.. And there's really no limit to "how high".

So at that point, the situation ends up looking rather silly, the server is going to be the primary data store whether we like it or not, simply because its the one that folks can connect to.

@restoration.software

I've worked with p2p stuff quite a bit, mostly around the network connections part of it and I I feel obligated to issue a warning -- on the "Peer-to-peer architecture research" post, you said:

* it will be PWA ( it will be a web site )
* phone as primary data storage site

AFAIK this doesn't really work because:

* limited data capacity of browsers (unless app is text-only)
* extremely low availability/"reachability" of web browsers

IMO you should plan to store the data on a server as the primary storage site.

Ultimately I think this "no permanent storage on server" goal inevitably leads to either "each user has a backblaze account and uploads their e2e encrypted data to an object storage bucket"
Or
"Each user runs their own server"

I think the issue of users not having data autonomy is easier to tackle as a social problem than as a technical problem. Even the best possible technical solutions still kinda need autonomous hosting.
Not to mention, I think the social solution just feels better anyways.

@hisaac ah nvm I thought you were talking about servers.

Yeah for macos VMs I'd use ansible or just shell with -e and -x set

@hisaac ansible is ok, but its slow, clunky, can be hard to debug, and since its written in yaml, prone to yaml syntax related bugs.

I think in terms of ease of use, its hard to beat docker / docker-compose for config management as long as your apps can be configured with environment variables.