Seeing an argument that Mastodon instances are hard to deploy (true of any web application) and that the solution is to focus on making something "serverless" that can be deployed to AWS or other clouds that provide proprietary "serverless" frameworks. Making applications that only run on giant cloud hosting providers is absolutely *not* the path toward technological autonomy. I think we need to better communicate free software principles here.
@dthompson FWIW, I'm considering hacking on a serverless mini-mastodon. But, you *can* wrap a set of node-based AWS lambda functions (for example) with an express server to run it independently. Lots of escape hatches that I'd plan to build in if I got around to actually doing it.
@dthompson Personally, I'd want to try something serverless not so much because it's easier to deploy - but because it might be cheaper and scale *down* more easily for many very small instances (i.e. my own single-user instance or a small low-traffic group instance) Admittedly, I might be wrong about that being handy though
@lmorchard I think those are valid reasons, but I think we need to look beyond Amazon and Google's cloud and do something that doesn't rely upon proprietary software as a service.
@lmorchard so this is kind of like free software that primarily supports proprietary operating systems, and secondarily free ones. it's nice that it works, but when the proprietary system is the default and best experience, it's not helping people escape proprietary platforms.
@dthompson I haven't used it, but there are also things like OpenWhisk - that could help reduce lock-in I guess?
Main thing I'm thinking about is that if I can host a thing for $1 vs $10-$70 per month - that's a huge win. And probably engineer it such that it could live elsewhere
@lmorchard reducing cost and server maintenance burden are both good goals. let's just keep our eyes on the prize while pursuing that. free software web apps need to be a lot easier to deploy.
@dthompson That's true, but it also seems like a chicken/egg thing. Or a maturity-of-serverless-tech thing.
If I can get a cheap & accessible thing running now, getting more hosting providers running fully OSS serverless stacks may have more demand when I want to move away in the future.
In the meantime, I'm not going to start a hosting company myself.
It's expensive too. Most are intended to run by themselves on a machine, so if you have a few of these, the cost gets high even wth containers and cheap vms.
And that's if you're good with tech. If you're not, forget it. Which is a shame, because it's not hard to install an app on your phone or laptop or even a NAS. So what gives?
Not any arbitrary app, they would have to be written for that platform (🥚/🐔). But the platform would handle a lot of the difficult stuff like users and auth.
I was thinking that a single-user version of Mastodon could be such an app. But I'm a long ways away from that!
@teleclimber @lmorchard @dthompson I agree with this: I've got some cheap VPSes running, but several things I've gone to (experimentally) deploy recently assume they get the whole machine. No go. Another road-block is Let's Encrypt assuming one cert per IP (which is typically "per VPS instance" at best)
@ng0 even that is admittedly a lot to ask of a lot of people. I think the effort to make things easier to deploy is good, and the people that make the serverless argument mean well, but I think they are missing the big picture when they advocate for it. the solution isn't easy deploys of free software to proprietary systems, it's easy deploys of free software to free systems!
@dthompson why does "serverless" always just mean AWS
@garbados I guess because they popularized it and are ahead of the other cloud providers in their implementation. setting aside my feelings for the name, I think the basic idea of abstracting away server details is good (I guess Heroku is really one of the first big services for this). we need a free "serverless" protocol or something so that there isn't lock-in.
@dthompson but it's still just "someone else's server". why not use neutral coordinators like torrents do to allow peers to act as servers for each other? the alternative is a bunch of siloing bs imo
@garbados moving to true P2P is a completely valid solution. this is kind of where my knowledge ends. ultimately I am for whatever reduces the number of silos.
@technomancy @dthompson even p2p isn't serverless. who coordinates peers? it's still servers. the term "serverless" just feels like unrepresentative hype for a generic ease of deployment. Dat uses public torrent infra to coordinate peers, as does IPFS; SSB has its own "pub" system that is basically a private tracker that seeds everything it coordinates, and it's still a server.
@kelly_clowers @garbados @dthompson kinda agree, but if you start going down that road it's not much of a leap to "any client which can perform uploads is also a server" and the term loses its meaning pretty quickly
"privileged frame of reference-less" might be a better term but I have a feeling it's not going to catch on
@dthompson totally. the tooling for p2p meshes is still in demoware hell but we're getting there; the interest and the labor is all at hand. there's some resistance to interop with server-based tech but IMO we'll get over it
@dthompson I'm not an expert in this but it could be nice to have a way to deploy apps in a self-hosted environment easily. Like that but in our own metal with no proprietary code in the middle.
@dthompson agreed. Where is this discussion?
@TheGibson there's no discussion. just something I saw. don't want to point out anything in particular. I don't know this person but they mean well. I just think it's a bit misguided.
@avolkov I am 100% opposed to omnibus packages, and app bundling that circumvents the system package manager in general. it's a security nightmare.
This is a good argument, and the difference is that gitlab instances can run on their own somewhere deep within an intranet, and mastodon instances have to be connected.
Still, there's definitely a value in streamlining the installation so if someone wants to do everything securely, they know what's involved, this would especially help people running their own instances with just a few users.
@dthompson Oh, it looks like this discussion has already taken place -- https://mastodon.social/@Gargron/100188629994429787
@avolkov I think omnibus packages happen when people make applications that are too hard to build and just punt on the problem completely.
@dthompson But mastodon is a genuinely complex web application, and complex web applications inherently involve a lot of setting up.
I can set up Mastodon from scratch, I can use ansible to do that as well, I'm fine, but for someone who doesn't now this thing and just wants a space for their art project -- it's either going to be installing Mastodon or not.
Omnibus lowers barriers of entry for the newcomers.
@avolkov it lowers the barrier to entry at the expense of a lot of other things. I think we can do better.
@dthompson Web applications don't have to be inherently hard to run, Rails is hard to run, and Mastodon's confusing docs aren't helping the matter. Pleroma is much better about this, and what I point people to who don't have beefy hardware and sysadmin experience.
Serverless hosting absolutely isn't the answer - better documentation, turnkey solutions on Heroku and the like are. We as open source developers have a tendency to assume everyone knows what we know.
@embr I think more high-level deployment tools are good, provided that we don't forget about the principles of user freedom along the way. writing something that can only be reasonably deployed in heroku isn't helping the greater cause. we need to control the entire stack, even if we only interact with it at a very high level.
@dthompson Fediverse home appliances (with user-serviceable parts) FTW.
@jaycie i installed mastodon on my smart fridge and now all I see are pictures of sexy dragons when I try to get milk.
@jaycie but seriously I like the idea of "plug and play" home appliances that have distributed services already setup... provided that the whole security updates thing can be handled in a reasonable way so people's homes don't become part of a botnet.
At some level, I think that social media servers are like table saws: There's a point of automation and attempted safety after which they paradoxically become more dangerous because people feel like they can be lax novices around them.
@jaycie this analogy makes me wonder if I'm one of those people because I use a SawStop table saw...
@dthompson I'm also reminded of how noise-making hardware gets installed on electric vehicles so that people don't walk right in front of silent cars.
I think there are values of "technical autonomy" that translate into "you can't make me care about the stack of dependencies below my competence level".
which bifurcates into those of us excited by, say, every piece of RISC-V news on the one hand and those who, say, consider thoughtless typeface selection a war crime.
Not *totally* orthogonal, but you get it: We have to pick which details to take for granted.
@dthompson sorry "technological autonomy"
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!