What iffing a possible scenario: Meta positions itself as an instance host, like how WordPress hosts blogs. “We’ll take the headache out of setting up an instance, but you control everything else!” Free? Low cost? Removing the technical hurdles of hosting your own instance could entice a lot of would be admins to go this route.
It gives the illusion of control, but Meta still back channel collects all data.
…and then a couple years down the line when people have come to depend on it and the code base has become simpler due to the platform capabilities that their hosting provides (nobody is self-hosting anymore anyway, because Meta hosting is so simple, easy, and cheap/free), they’ll start exercising more control anyway. “Come into compliance with our corporate terms of service and Community Server Guidelines™ or you’ll lose our hosting. Oh shit, there’s nowhere else for you to go for hosting anymore? Gosh, gee, shucks! What a shame.”
But in your scenario, how could there be nowhere else to host? In theory, I can spin up an instance on my own physical server, obtain space on AWS, or install my own hardware in a CoLo IX. Your scenario assumes Meta owns all of the hardware on the net, or somehow acquires sole rights to the ActivityPub codebase.
What I’m saying is that Meta will create a platform on which Fediverse instances can be hosted. They’ll add features to that platform that make it easier and easier to host such an instance. They’ll offer APIs or whatever that’ll support instances in ways that other hosting environments won’t. And then when the code base has changed to depend on their particular hosting environment, they’ll use the power that gives them over us.
Glad you brought up AWS. It and other tech companies have created kubernetes platforms (Amazon’s is EKS, which runs on top of AWS and its services like EC2) that make it really easy to spin up clusters, auto-scale them, use custom objects that are specific to their platforms, control external access to them, monitor them, etc. While “bare metal” kubernetes implementations exist, they are a royal pain in the ass to setup and run, and they support a fraction of those bells and whistles. And as time goes on, the difference between one of these “native cloud environments” and anything anyone would (try to) setup themselves gets greater and greater. And systems that are developed for kubernetes rely more and more on those bells and whistles (e.g. despite kubernetes being allegedly agnostic to what it is running on underneath, companies choose to support “just EKS” or “EKS and GKS” and no other environments). Perhaps a particular software suite depends on PersistentVolumes that can be moved between nodes, or mounted on multiple nodes simultaneously, or whatever. EKS might support this when other environments don’t. Or a custom AWS annotation on a LoadBalancer Service might provide some kind of control that the software depends on to function properly and be externally accessible in a way that the software depends on. So this is a nice corollary to how things might go with the Fediverse.
Ah I see what you’re saying, thank you for clarifying. It seems then that a primary goal should be to ensure a form of feature parity that rivals anything Meta delivers, but within the open source realm. Considering the existing codebase (for Lemmy at least) is licensed AGPL3, wouldn’t any derivative works be required to be released under the same license? Forgive me, I’m still getting up to speed on all this, and I’m quite far removed from FOSS these days.
It’s not necessarily so much the license, but resisting the temptation of taking advantage of things special to the hosting environment, and staying as cross-platform as possible, supporting a range of accessible environments no matter how tempting it is to take advantage of the benefits of one (or some) over others.
good theory, I’m sure they will offer custom domain names as well to sweeten the deal since I doubt most people want to be stuck with a .meta handle or something
What iffing a possible scenario: Meta positions itself as an instance host, like how WordPress hosts blogs. “We’ll take the headache out of setting up an instance, but you control everything else!” Free? Low cost? Removing the technical hurdles of hosting your own instance could entice a lot of would be admins to go this route.
It gives the illusion of control, but Meta still back channel collects all data.
My money says you’re right.
Time to learn how to host your own instance everybody.
…and then a couple years down the line when people have come to depend on it and the code base has become simpler due to the platform capabilities that their hosting provides (nobody is self-hosting anymore anyway, because Meta hosting is so simple, easy, and cheap/free), they’ll start exercising more control anyway. “Come into compliance with our corporate terms of service and Community Server Guidelines™ or you’ll lose our hosting. Oh shit, there’s nowhere else for you to go for hosting anymore? Gosh, gee, shucks! What a shame.”
But in your scenario, how could there be nowhere else to host? In theory, I can spin up an instance on my own physical server, obtain space on AWS, or install my own hardware in a CoLo IX. Your scenario assumes Meta owns all of the hardware on the net, or somehow acquires sole rights to the ActivityPub codebase.
What I’m saying is that Meta will create a platform on which Fediverse instances can be hosted. They’ll add features to that platform that make it easier and easier to host such an instance. They’ll offer APIs or whatever that’ll support instances in ways that other hosting environments won’t. And then when the code base has changed to depend on their particular hosting environment, they’ll use the power that gives them over us.
Glad you brought up AWS. It and other tech companies have created kubernetes platforms (Amazon’s is EKS, which runs on top of AWS and its services like EC2) that make it really easy to spin up clusters, auto-scale them, use custom objects that are specific to their platforms, control external access to them, monitor them, etc. While “bare metal” kubernetes implementations exist, they are a royal pain in the ass to setup and run, and they support a fraction of those bells and whistles. And as time goes on, the difference between one of these “native cloud environments” and anything anyone would (try to) setup themselves gets greater and greater. And systems that are developed for kubernetes rely more and more on those bells and whistles (e.g. despite kubernetes being allegedly agnostic to what it is running on underneath, companies choose to support “just EKS” or “EKS and GKS” and no other environments). Perhaps a particular software suite depends on PersistentVolumes that can be moved between nodes, or mounted on multiple nodes simultaneously, or whatever. EKS might support this when other environments don’t. Or a custom AWS annotation on a LoadBalancer Service might provide some kind of control that the software depends on to function properly and be externally accessible in a way that the software depends on. So this is a nice corollary to how things might go with the Fediverse.
Ah I see what you’re saying, thank you for clarifying. It seems then that a primary goal should be to ensure a form of feature parity that rivals anything Meta delivers, but within the open source realm. Considering the existing codebase (for Lemmy at least) is licensed AGPL3, wouldn’t any derivative works be required to be released under the same license? Forgive me, I’m still getting up to speed on all this, and I’m quite far removed from FOSS these days.
It’s not necessarily so much the license, but resisting the temptation of taking advantage of things special to the hosting environment, and staying as cross-platform as possible, supporting a range of accessible environments no matter how tempting it is to take advantage of the benefits of one (or some) over others.
Gotcha, makes sense. Thanks for the replies!
good theory, I’m sure they will offer custom domain names as well to sweeten the deal since I doubt most people want to be stuck with a .meta handle or something