I'm interested in stories that span for several years, because if someone installs and maintains something for 1-2 months, then this is not really an indicator of anything. Part of the difficulty comes with system updates, application updates, migration of configuration files, hostile environment like DDoSes of angry people, hacking attempts, deprecated docker containers, incompatible library versions, changed policy of python scripts on some Linux distro, than span over multiple year periods. I would be interested in hearing what people have to say, but including the later subjects as well.
Yeah my self hosting story started in 2003 and involves moving all of those things to many different servers, etc. I had problems with hacking when I used WordPress, the server has been taken over 2 times. Once I stopped that those problems stopped too. And because I have only 1 person instances I don't get much attention of angry people.
The depricated PHP version is my biggest problem until now, I used a lib written in PHP 4 which are now incompatible with PHP 8 and I can't easily rewrite it to make it compatible. So this one is still running on PHP 7, but I will need to do something about it in the future. The best would be to export everything into static HTML but that's also not quite straight forward.
I started to look into hosting my own Lemmy instance to have full control over my data and not have to worry about a server shutting down, but after seeing it takes 2-3 docker instances, I decided not to worry about it and let someone else do it.
Well, a couple things occurred to me when I realized it was at least 2 instances.
First, I'd have to get them talking to each other. I am not an expert at Docker, and I just do the most basic stuff with it.
And second, I think they'll need to be reachable from the web, so I'd want to host them somewhere out in the cloud, and not on my home network. NearlyFreeSpeech doesn't offer Docker hosting yet (that I know of) so that means paying more for somewhere else for it...
And at that point I decided I didn't care enough about the benefits to deal with all the downsides, and just signed up on a Lemmy instance. It was actually the second instance, because the first one had stability issues. I then realized I didn't like how that instance was being run, and signed up on third, which I've been happy with and it's been relatively stable. At least, when it had problems, so did most other big Lemmy instances.
I mean, asking them to plop their cli docker setup into a yaml file isn't exactly a difficult task. I think it's probably more correct to consider docker-compose an integral part of docker rather than a superfluous abstraction layer.
Yeah with Lemmy it's pretty extreme. But to be fair, Lemmy is the only fediverse software I run in docker, Mastodon and PeerTube work easy enough without. But Lemmy being written in a compiled language makes it more difficult to get everything installed and set up to compile it. Once it's done it's very lightweight in comparison to especially Mastodon, which is nice.
Docker compose makes it relatively easy to coordinate multiple containers. But to answer your actual question, yes, that’s possible though definitely not recommended for standard hosting, it’s called DiD (docker in docker) and is fairly common for CIs.
It is common to use --privileged (or -v docker.sock) and run docker commands inside docker. But then you're not really in the container, you may as well be on the host.
I think genuinely containerizing inside an ordinary container, without --privileged, would mean taking extreme compromises like bocker or proot.
The Nextcloud All in One (AOI) images takes another approach, which is use the first image to launch the other needed images. So it lets you avoid docker compose at the cost of needing to pass the docker socket to the AOI container.
I tried this and I did not enjoy it. A docker container with access to docker socket is so cursed.
I kept having issues, like I tried to stop the container and it left all the extra containers it made running. They also had different network settings than the ones I set on the parent container. I don’t remember the exact issue but I had to manually adjust the network that it made- because it just made its own and ignored the one I assigned the parent container too.
It was the easiest way to get Nextcloud running but I immediately stopped it. I don’t want Nextcloud able to tamper with my other docker containers. I want it contained.
I haven’t yet had a chance to figure out how to get their containers running normally.
That would also discourage me from setting it up, so I don't blame you, but just asking, was there not a docker compose somewhere for setting this up. It seems like that would make things a lot easier.
I didn't go deep into looking for one. It's possible it exists, but the little bit of research I did into it didn't reveal it, and I didn't want to figure out how things fit together.
Now that you say that, it seems obvious that it must exist, and I just missed it.
An “instance” here being just a walled-off process running inside its own chroot environment. IIRC Lemmy needs 4: frontend, backend, database and imagestore. It doesn’t need much resources when running, though.
How much data throughput does it use in a typical month? My home connection is heavily metered because I live in a failed state with regulatory capture.
That massively depends on how many groups you subscribe to. I'm running my local instance for slightly over 6 months now, have subscribed to around 30 groups/communities/subs and my local storage shows 2.7GB in the pictrs directory and 2.8GB in the Postgres directory.
One huge shortcoming of the Fediverse as currently implemented is that you have to use a different ID for each app, ie tube.jeena.net/@jeena, toot.jeena.net/@jeena, etc. What if you want to use the Mastodon UI to write a comment on a video? Your comment is going to use a different ID than the one you normally use to interact with videos. Given this, what's the point of federating these different apps with each other?
We need to figure out a way to share a single id across apps. Could be as simple as having a single URL as your user ID profile, and listing multiple public keys which are used by your various apps. The keys can be rotated as necessary since your URL is still the final authority on control over your identity.
In practice, federation works _great_ when the apps all have the same basic structure, and gets pretty rough otherwise.
Mastodon instances basically _work great_ with each other, and with Friendica and Calckey too, since they have the same Twitter-like structure. Lemmy and Kbin - and all instances thereof - can chat with each other without issue too, since they have the communities + threads structure in common.
But trying to get Mastodon and Lemmy to talk to each other is 1. surprisingly possible, and 2. kind of annoying, since they speak the same protocol but have different structures of communication. And never mind other ActivityPub applications like BookWyrm or WriteFreely or PeerTube.
To expand on this a little the two services make use of different well-defined objects in the AP standard. Lemmy communities are Groups in AP and top level posts are implemented as Pages (rather than Notes). As it stands Mastodon only has basic support for these two but a rework of Groups is listed on the roadmap as in-progress (https://joinmastodon.org/roadmap).
Do they really need to work that differently though? It seems to me that almost all of them can be represented as trees of text entries. Blog+comments, HN/reddit threads, Stackoverflow QAs, DMs, Discord/Slack, forums. These are all just text trees with optional attachments and/or links to other content (images and videos etc). Why not build that tree structure into the protocol (all you need is 1 parent and 0+ children for each entry)?
Lemmy has the concept of "communities" - subreddits, basically. On Mastodon, you can follow a Lemmy user and see their posts+comments exactly as you'd expect. And you can follow a community too! To Mastodon's point of view, the community is a single user that "boosts" (re-tweets) every post and every comment made within. So following a moderately active community from Mastodon will absolutely flood your feed with 100% of the community's user activity.
Meanwhile, Lemmy doesn't do direct messages or use hashtags as a first-class feature. So if a Mastodon user tries to DM a Lemmy user, or a Lemmy user wants to follow a hashtag, they're out of luck.
And again, there are other Fediverse apps with even different models than these. Gitea, Forgejo, and GitLab are going to adapt ActivityPub to all federate with each other - this is a huge win, of course - but would we expect someone to make or review a pull request from their BookWyrm account?
They absolutely do not. This is more of a state of the ecosystem sort of problem. I think a lot of developers were wary of getting into how some of the more esoteric AP objects should work. It's important to note too that while we have a standard in the form of AP a lot of the decisions about norms for these less common message types simply have not been made, but we are definitely moving in that direction as more services add AP integration.
This is impossible, sorry. blockchain is before anything else, a very opinonated implementation of applied economic theory. The technology is secondary and consequent to the belief that people as a whole cannot be trusted to take care of things that they do not pay for. I say this is someone who is far from a fan of blockchain anything, but there's no getting around the fact that it is impossible to divorce it from its core principle, which is that pay to play has to be baked into the system at its deepest foundation.
And as soon as you introduce this, pay for the many becomes profit for the few, and inevitably markets, trading, and rent-seeking cartels form who swiftly capture the natural value confluence points of the system, reversing any decentralizing tendencies it may have, and collapsing it back towards centralization in order to consolidate and protect their advantaged position.
If all your target users are comfortable with the tradeoffs of systems built on blockchains (ie private key is the source of authority), you're probably looking for Nostr.
For context the only things nostr have in common with Bitcoin is using secp256k1 for identity. It has been cooked mainly by bitcoiners but AFAIK part of the driving force was specifically to avoid the "everything is a blockchain with a native token" situation.
Naturally you will find lots of bitcoin people using and developing clients (hence the Lightning integration on most clients) but apparently it has been picking the interest of other groups. There seems to be a thriving Japanese community.
I personally think initiatives like activiypod and vocata are interesting and would solve it well. They focus on being standard Activitypub implementations that others can subscribe to.
I've tried various Fediverse services such as Mastodon and Lemmy, and, based on my experience, I've noticed a stronger tendency towards censorship, self-censorship, and ingroup behavior.
In comparison, platforms like Twitter and Reddit still feel freer. But overall, the best solution is to use your own website for everything. But too much censure really stifles social media.
Instead of "censorship", I'd say "moderation". To pick a random example, suppose you're on an instance run by, and dedicated to, right-wing politics. It may block connections from servers meant for and run by devout communists. The reverse would probably also be true. No one's saying fascists or communists can't run their own server. They're saying "I don't want to hear this stuff".
It's legal to be an anti-Semite, but a Jewish instance doesn't want any of that nonsense. It's legal to be a white supremacist, but a server for black people doesn't want to deal with that trash. On the fediverse, instead of having a one-size-fits-all policy like "all legal speech is allowed" or "no anti-trans content is allowed", each group of users can choose for themselves who they want to talk to.
That's the opposite of censorship. I own a Mastodon instance and I've disconnected quite a few despicable servers, because that's what my users ask me to do. Users who thing I'm too strict or too lenient can move to another server more aligned with their own desires. I'm not denying those other groups the right to publish whatever disagreeable content they wish to. I'm just saying we don't want it here on our server.
This is true, but it does reinforce and cement in- and out-group dynamics. You're more likely to be exposed to unfamiliar ideas on a place like Reddit, specifically because you don't _have_ to pick an explicit bubble. When picking a Lemmy instance, you kinda end up aligning yourself with some worldview, and letting some set of strangers curate your environment for you.
Incidentally, that's sort of the weirdest part of signing up for Lemmy. I can't be the only one who got to the "Pick an instance!" step and got kinda paralyzed. I'm a programmer, should I sign up to a programmer-centric instance? But I also have hobbies, political views, favorite forms & genres of media... Should those take priority? And by picking one of them, what curation or censorship am I going to be subject to?
I appreciate the fact that Lemmy isn't under the thumb of one monolith, and that I can bounce from once instance to another if the first isn't working out. But I also like the 'big-tent' feeling of Reddit, where I can sub to all kinds of subreddits, even if the two groups don't get along at all.
I see what you're saying. OTOH, you can belong to several Lemmy instances at once. In that sense, it's kind of like phpBB. Which forum do I want to join? The set that covers my interests today! Maybe you like to argue about Star Trek vs Star Wars on a Sci-Fi Lemmy/phpBB, and learn to make soufflés the French Cuisine board of a Cooking Lemmy/phpBB. You don't have to join the Cooking instance and then limit yourself to looking for fellow chefs who also like Firefly.
Yeah, that's true. Others have said it elsewhere in this thread, but I wish identity was more independent in the fediverse. If federated services just used OAuth or something, your identity could be portable between Mastodon, Lemmy, and PeerTube, and you could use several instances without having to manage a bunch of different accounts. Heck, you wouldn't necessary _need_ accounts, they could just be implicitly created for you when you posted on a server.
I'm with you there. I'd love if that were the case. Even if it were only for associated services, like having a domain-specific SSO for mastodon.example.com, pixelfed.example.com, and lemmy.example.com so that you didn't have to maintain 3 accounts for those 3 services owned and operated by the same people, it'd still be super useful.
There's a shared covenant and there's shared block lists, both of which heavily influence what the norm is on the larger Mastodon network. Perhaps an even larger dynamic are activist-type admins that have an extremely low tolerance for content countering their political beliefs and will blackmail other admins into enforcing a block of a user or entire instance.
None of this is a shocking revelation as a large portion of older Mastodon users are known for their excessive safety-ism. It's a perpetual conflict on the network versus those that want to be more forgiving and pragmatic.
Anyway, the bottom line is that mainstream Mastodon is a left to far-left network, and content is moderated as such. The idea "just pick another server" doesn't really apply.
I vehemently disagree. In practice, I don't use those blocklists and neither do the neighbor instances we most heavily interact with. I'll occasionally hear from a friend that "new instance XYZ is sharing loli porn" or "instance ABC's moderators quit and now it's flooded with swastikas", and then I (and my neighbors) will verify whether that's true, and then disconnect those specific instances.
I also think mainstream Mastodon is only left to far-left in the median, because far-right instances tend to be more of a pain in the ass to be around than far-left ones, and thus get themselves banned more often. If there were far-left instances running around posting memes "joking" that we should kill minorities, I'm confident they'd also get disconnected quickly.
Put another way, I don't recall ever disconnecting with an instance because of its users' opinions, unless those opinions were utterly vile to the point that I'm completely unwilling to hear "their side of the argument". Most blocks are due to bad behavior, not unsavory thought.
I didn't mean to suggest that you're somehow unreasonable in how you run your server, I was mostly commenting on the larger concept of mainstream Mastodon.
Indeed, right to far-right doesn't stand a chance there so they get blocked. They effectively move to a darkweb situation where you never see their content unless you're really trying hard to look for it.
What remains, mainstream Mastodon, is moderated to the left, if not far-left. Or perhaps it's a very vocal far-left minority silencing the rest. It's of course not universal across the entire network, but roughly the vibe of the network.
Nah, I didn't take it that way. I know you were talking about the network as a whole, not me in particular. I was just using myself as an example.
I still see the spectrum like:
(far left nuts) (left) (middle) (right) (far right nuts + poor behavior)
I far the far left opinions as annoying as the far right. I disagree with both of those extremes. However, in general, the far left tends to be annoying but reasonably well behaved and self-policing. We've had many more mod reports about far left individuals than far left servers. On the far right, it's more common to get a whole cluster of misbehaving idiots in one poorly moderated place, resulting in an entire instance getting blocked.
In my opinion, based on my experiences in the Fediverse, if the network as a whole is shifted to the left, it's because the far right is more likely to get itself kicked out because of their behavior. It's like taking a Gaussian curve and lopping off 2 stddevs above the mean; the new mean is farther to the left, but only because it lacks the pull from the extreme right.
This is inspiring. We're seeing some momentum now with the internet pendulum swinging back in the direction of the distributed and federated platform that it was originally intended to be. Interoperability via standards-based protocols provides choice of providers and methods, and helps to limit the influence of walled gardens and ad-based services. I expect to see a number of services and providers arising that will offer good data privacy controls and an ad-free experience with funding via a reasonable monthly fee. Well done!
I have a question that I was hoping the video would answer, but I didn't see. The Fediverse is always described with that interconnected diagram where everything talks to each other over ActivityPub. But I never see that in practice.
For example: If I have a mastodon.social account, how does that work with pixelfed.social or tube.jenna.net? Do I use my mastodon.social account to sign up to those other services? Or to follow users on those other services? How do the clients handle the fact that they are different services?
You use your mastodon account to tell your mastodon instance to follow a user on the pixelfed.social instance. Your mastodon instance starts getting a feed of all the posts by that user from the pixelfed.social instance and displaying them to you in your mastodon timeline as if they were mastodon posts.
This works because while pixelfed and mastodon and tube.jenna.net display things differently, the things they are displaying are in fact very very similar. Posts by users, consisting of maybe a video, maybe an image, maybe a reference to a post they're replying to, and some text. Ultimately it will be up to the individual implementation what to do with posts that are different enough that they can't figure out a reasonable way to display them.
> The Fediverse is always described with that interconnected diagram where everything talks to each other over ActivityPub. But I never see that in practice.
Not sure what you mean by this—it definitely comes up a lot in practice. The top story on HN right now is an example of this in practice—it's a post from social.hackerspace.pl, which has been shared to all of the users followers on different servers. You can take a quick look at the list of reblogs on that post to see how many different servers users use: https://social.hackerspace.pl/@q3k/111528162462505087/reblog... I count 17 different servers in the first 20 users listed. Many of these are deployments of Mastodon or Akkoma, but they're all completely separate servers talking to each other over ActivityPub
> For example: If I have a mastodon.social account, how does that work with pixelfed.social or tube.jenna.net?
You can use your account and client on mastodon.social to follow accounts on tube.jenna.net and pixelfed.social. These accounts are displayed inside of the mastodon.social UI. You don't "sign up" for those instances in any way, they're just an integrated part of your following feed.
> How do the clients handle the fact that they are different services?
There is no special logic needed from clients. For Mastodon specifically, the local server that you're following from will handle the logic of translating the ActivityPub JSON sent by other services into the more limited "Mastodon API" format that clients expect. This has pros and cons—it means that clients are able to handle a more limited and predictable set of posts, but it also means that some remote content gets "squished" down into that format, just like e.g. viewing a blog inside of an RSS reader. Other clients generally use their own similar domain-specific API format
one correction: the Mastodon API is actually more expansive than ActivityPub, not more limited. Pleroma and Misskey implement additional protocols on top of ActivityPub, like WebFinger, in order to be able to federate with Mastodon properly
>it also means that some remote content gets "squished" down into that format
this is true but it's usually content going the other way: FROM a Mastodon instance TO something like WriteFreely that isn't a Twitter clone
By "the Mastodon API" I'm referring to the REST API used by Mastodon clients, not the activitypub "plus" API used by other servers to federate with them.
> FROM a Mastodon instance TO something like WriteFreely that isn't a Twitter clone
I understand that it may appear like that from a user perspective, but from a protocol perspective the ActivityPub representation is strictly more generic and extensible. Both directions (from mastodon and too mastodon) are very, very lossy. All mainstream servers (except maybe pleroma derivatives) do this kind of "squishing", which is a sad reality of client design and not what the ActivityPub spec was intended for
>All mainstream servers ... do this kind of "squishing", which is a sad reality of client design and not what the ActivityPub spec was intended for
I understand what you mean by "the Mastodon API" but I think we're talking past each other; this does not seem like a client design problem but a protocol problem.
I would like to contend that the ActivityPub spec is too vague and thus clients are forced to do this "squishing" in order to find a portion of the spec that is sufficiently well-defined as to actually be practical for a specific use-case like a federating Twitter clone.
As far as I can tell, there's an echo of this lack of definition in the ActivityPub (and actually more specifically, in the ActivityStreams) specification if you do a tour of the ecosystem of implementations, you'll find that almost all of them are in dynamically typed high-level languages like Ruby (Mastodon). Implementations in languages like Go where JSON deserialization must be defined per-type have a very hard time with ActivityStreams and you'll find that Go implementations of ActivityPub like go-fed are much more narrowly scoped in their functionality in order to avoid this problem.
I have wasted many, many hours on ActivityPub, and I am extremely sad to make this comment, because I understand why it was invented.. but I'm not sure it's really good enough to achieve its goals.
The fact that some Go libraries use struct-based deserialization for processing ActivityPub is frankly an implementation issue. Your language choice should not make a difference in how easy you find it to implement something. go-fed could have been implemented 10x more easily using maps, without having to resort to reams of code generation to implement things that dynamic languages implement "trivially".
My feeling is that nobody has given a serious AP C2S client implementation (where the narrowing / "squishing" happens on the client side, as defined by the spec, and the server-side is agnostic) a serious effort. It increases client complexity, yes, and there needs to be extensions to the AP spec to make it work, but I think there are a lot of benefits to it that haven't yet been fully explored.
I don't think the future of ActivityPub is locked-down implementations like Go that have super strict type safety rules. That's just at odds with what real decentralized protocols have proven to work (HTML, HTTP, SMTP, MIME—all have "open ended" extension mechanisms). I think a pluggable client infrastructure that allows multiple different "types" of clients to share the same agnostic backend server is a much stronger path forward for future development.
There are some initiatives that are doing more what you are looking for, vocata and activitypod. These treat activitypub more like a modern email server, that recieves and sends activities to different federated servers.
In a world where those would be used, "apps" would just subscribe to the activities that interest them, and you would be one user that adds apps to your system. You'd be able to have something closer to google suite, where your calendar app can display notes from your note app, or your notes app could display shared notes, comments etc.
Today though, most of the big activitypub players decided to implement their own activitypub server and don't really follow the protocol to the letter, so unfortunately it's not as interoperable as it could be. You also need to have an account for each service, which is unfortunate.
You just follow those users at their @user@pixelfed.social or @user@tube.jenna.net handle. Depending on the service you are using there can be caveats (I think pixelfed only tracks new content from mastodon after you follow the user) but otherwise it "just works".
caveat: This only works as long as your instance hasn't de-federated those instances.
It’s federated like email. If you have a Gmail account, you can talk to people with a Yahoo account. You can’t use your Gmail account to log into another server, though, unless that server adds code to specifically support it. They’re separate servers operated by separate entities.
I haven't seen anybody else talk about what the experience of following somebody from another service is like on the user-end.
Following pixelfed accounts from Mastodon is actually fairly straightforward. You simply see them as a tweetlike message with an image attached. One caveat there is that Mastodon does not allow for as many attached images as pixelfed, and I believe will simply drop any images after a certain point (I want to say max size is 4).
Following a peertube account or channel (you can do either) will show a post whenever new videos are uploaded. You can find the OP on mastodon at https://mastodon.social/@jeena@tube.jeena.net. One neat bit of functionality is that if you put all of your peertube follows into a single list, you've basically got a chronological subscribed page (a la youtube). Also take note that comments can be left on either the peertube site or from within mastodon.
ActivityPub would not appear to be a focus for the mainline Mastodon team. My tests show that most ActivityPub endpoints of the main Mastodon server software are not CORS enabled so are unreachable by webapps. They are public endpoints and should obviously be CORS enabled. For a HTTP-based protocol, this is a glaring oversight. (It's fixed by at least some other Mastodon servers like Glitch.) Most other ActivityPub implementations correctly enable CORS. CORS is just an example of the treatment that ActivityPub gets.
The ActivityPub endpoints are not CORS enabled because requests to those endpoints are supposed to come from homeservers, not from users' clients. That's the server-to-server protocol, not the client-to-server protocol.
Mastodon devs admit some endpoints should be CORS enabled, and did so. Whatever you do to make this fact "fit" your logic should be extended to the other endpoints. Glitch already extended it.
If pixelfed and mastodon are federated with each other, you should be able to view users and posts from both sites on either site - no need to sign up for both.
You can't (yet?) log in at other websites, but you can follow anyone from any fediverse service. I follow accounts from PixelFed and PeerTube on my own self-hosted version, which feels very web native and self evident when you get used to it.
What does the storage/CPU look like? That amounts to the CPU time for three cores, roughly, but it could be spent on waiting (eg: I/O)
Apologies if this is covered in the post, if so -- tell me to kick dirt. I've been posting while I should be working! The plan was to check it out later (promise!)
I'm using Hetzner and a CX31 shared VCPU https://www.hetzner.com/cloud + 250 GB volume. I want to move to object storage some day because it's cheaper.
I started with the cheapest one, the CX11 but it was just not able to run all the services the load would go up to the hundreds and the server would just block itself. The CX31 has 2 CPUs and 8GB ram which seems to work well with the load I have for now.
Video played perfectly for me, though I did leave it at 1x because I didn't want to miss anything with his accent.
My only mild disappointment is he seems to feel that Mastodon is free of censorship. I've never installed or reviewed configuring Mastodon because my understanding is the someone, somewhere, can somehow interfere with what a user sees in a feed.
Anyone familiar with this? Is it just default install configuration that leads to this behavior?
If you host your own instance, you have full control. If you don't host your own instance, then whoever hosts it for you has control (as they are the admin for your instance).
This means you tradeoff someone administrating the server and moderating content (shared instances often have a TOS) for full freedom. i.e. If you self host you have full, manual control for better or worse.
Yeah, but it's email without spam protections of any kind. I ran a homeserver for a little while and didn't want to store the kind of content that came flowing in through the federation endpoints from the moment I interacted with another server.
I'm not sure exactly how Mastodon/Pleroma crawl remote homeservers once they're discovered, but I saw a lot of objectionable content on the "Known Network" view from users I did not follow and that I did not want on my machine, nor did I want to wade through and delete things.
That's not the default behavior. Mastodon has 3 built-in timelines:
- Your "home" TL with people you follow, and the stuff they post/repost/etc.
- The "local" TL with the users on your server.
- The "federated" TL that's the union of all the people that users on your server follow. Like if you and I are the only 2 people on that instance, and you follow {A, B, C}, and I follow {B, C, D}, then the federated TL will have posts from {A, B, C, D}.
That's it. There's no proactive reaching out and pulling in content from the rest of the fediverse. The one other possibility would be if you configured your instance to use a "relay" of content from other instances you wouldn't normally connect to, which is something optional you have to add.
One issue I've run into with unexpected NSFW in my federated TL on a single user instance is when people I follow reply to an unfollowed account's NSFW post, when the reply gets sent to my server it fetches the parent post
Nothing is censorship-free, but the social web (the fediverse) is just a bunch of websites. A website can be blocked at the DNS level, but that is exceedingly rare. Other websites may choose to block your site for their community. That is the way of the web.
Each site has different rules and cultures. It's convenient to sign up at someone elses site, but you give up some control. Want to live by your own rules? Put up your own website and participate in the social web that way!
I run my own GoToSocial website, which is a Go project that is much simpler to install and maintain than Mastodon. Hit the sweetspot for me, at least.
It happens, but with limited effect and restricted to certain jurisdictions. My point is that the social web is not owned or controlled by any one commercial entity, just like the rest of the web.
The pirate bay is blocked by law in Norway by the ISPs DNS servers, but is trivial to get around. It is a very soft kind of censorship, which is the beauty of the Internet.
that's archive.ph's doing because they don't like cloudflare (there is a DNS extension where a DNS resolver forwards the prefix of the users IP to the DNS server of the site. Cloudflare does not use that, and archive.ph/.is says that they break their ability to properly host their site by doing that)
It's the same censorship-model as with mail servers: You can use a big shared hoster and the rules of that hosts country and their policies apply. You can run your own and you will have to deal with any local legal requirements and get to set (but also have to enforce) your own policies. In reality, (self-)censorship is the smallest of your problems, spam and abuse of your service is what you'll be mostly dealing with.
For a small instance with only a handful of friend and family accounts that effort (spam, abuse, legal stuff) will take less than 1h per month. On a large instance that can become a full persons job.
Source: I'm running my own fediverse instance since 2011 (using Friendica, predates Mastodon) - as well as my own mail server.
Censorship policies are dependent on the specific instance where you signed up and they are almost always very clearly spelled out. The main instance for example clearly spells out five rules including four forbidden categories here: https://mastodon.social/auth/sign_up Contravening these rules can absolutely get you deplatformed.
I've also seen the signup page of other instances having dozens of categories of prohibited posts.
Is there a way to have like a backup cloud solution in case my electricity goes down at home and my self hosted server shuts down? Some cloud service that does nothing most of the time except backing up data from the self hosted server from time to time and monitoring if it's up and connected to the internet, and if it's not then it takes over and offers the same service.
Not that I'm aware of. You'd need to run a reverse proxy somewhere and then point it to your home server as a default but having your other server as a backup running the software at the same time. The big problem is how to store the data on both servers at the same time, especially small texts which are in the database.
Thinking out loud here, but if this is public-facing you can put together a static archive using something like ArchiveBox/SingleFile and have the monitoring server serve the files and update the DNS entry when it detects downtime past a certain threshold.
Sure, it won't offer exactly the same affordance but the OP mentioned rare downtimes like electricity going out (rare here is used generously, obviously some places see this happen often).
Providing a read-only, static version of the services, particularly toots and blog posts, while the origin is unreachable is straightforward and inexpensive.
Somewhat related, the Solar Protocol [0] does something like this to host websites across an array of solar-powered servers across the globe.
http://solarprotocol.net/
Why don't more people self host / host everything themselves these days in the age of privacy?
How can we make more people self host their data rather than giving it to corporations?
A start might be to tell people to use extensions that are adblockers and to disable javascript on websites and even use and setup pi-holes to take back their data and privacy.
There must be more that can be done here but it is a start!
> Why don't more people self host / host everything themselves these days in the age of privacy?
Because it's a pain in the ass and people don't care enough to. People don't want the fediverse, they want an app. They don't want to know about cloud and infra primitives, they want their photos in their phone and for them to be safe and shareable. They want their iMessages and WhatsApp to JustWork(TM).
> How can we make more people self host their data rather than giving it to corporations?
You cannot. Make non profits to manage this infra. Wikipedia, Lets Encrypt, etc. Hacker News is a benevolent dictatorship funded by a VC fund and run by someone passionate about the work. Incorporate a 501c3, spin up a deposit account, and start sourcing donations and funding to pay for infra and people.
This is not a doomer comment. Enable the power admins and passionate folks to deliver a great experience to normies with as little effort as possible. Literally how Wikipedia functions: datacenter, paid admins, passionate volunteers curating bytes.
(Would be cool if Cloudflare supported one click deploy of Fediverse tools into their edge cloud; scale when you need, get your data out of R2 and databases on demand so you're not locked in; having to pay for infra is inevitable, that is to be solved for)
I do not fault the r/selfhosted masochists, no kink shaming here, but recognize outliers vs the mean. Go talk to average folks for 15-60 minutes on the street about what social (video, communities, threads/twitter/x/whatever, etc) means to them, this will help calibrate perspective. This is just product and user research. Find out what people want and build it, don't build what you think they want. Product market fit is not just for startups.
Generally I'm for self hosting everything that I can, I just can't help myself pointing out that currently the most popular thread on r/selfhosted is "I'd rather kill myself than host SMTP again (self.selfhosted)" :D
Then a goal should make the responsibility as minimal as possible (buying a box, inserting a thumb drive and answering a few questions and you're off to the races).
You misunderstand. Responsibility cannot be avoided.
- power's out at your house. You should have bought a UPS.
- internet's out at your house. You should have a router with a backup connection.
- security exploit in the wild. You should have configured automatic updates.
- update repo changed URLs. You need to change the config.
- you enabled open signups, and now strangers are distributing MP3s from your images directory. You need to kill those accounts and change the config.
- you let your cousin have an account, and now he's in a flamewar with half of Australia (which he thinks is Austria, and also he believes is ruled by the Illuminati). You need to shut that down and talk to other admins about getting off of their blocklists...
- Your ISP is [ISPs are, to your 2nd point] actively hostile to running "servers" from your connection, so you must either pay a ridiculous premium for that privilege, or jump through hoops to evade their intentional breakage.
- Your other cousin does something illegal (sells drugs, posts revenge porn, threatens a public official) using your host and now the police are knocking down your door in the middle of the night and dragging you in for questioning. Even if you avoid charges, your neighbors eye you suspiciously from then on.
self hosting is how much of that are you willing to put up with.
Everything is a possible point of failure. Of those there are those you can control and those you can not. Just adding in a DNS resolver ups the number of possible points of failure by 2. Mix in a proxy server with TLS rewriting. Add in a few more. Add in your docker source of containers is gone more failure. That on top of your usual 'computers are broken in weird ways' most of the time.
Outsourcing that to a 3rd party is tempting, very tempting. But you are also sacrificing other things to do so. So you have to balance those two opposing forces. Sometimes picking up the phone and saying to someone on the other end 'fix it' and they fix it is useful. Other times you digging thru hundreds of forums (or chatgpt these days) and figuring out what is wrong is interesting too and has its uses.
That most people just sign up for something and just want it to work. I totally get.
More like https://discourse.org/. You can run it yourself, but you can also just have them ding a credit card every month and not think about it again. Wordpress has Automattic, and I'd like to see the same for Peertube and Mastodon. With Mastodon, one can then go to folks and say, "Heh, here is a turnkey solution to migrate to for your 1:many and social interaction needs, fully managed." As long as these applications support an S3 compatible target for backups and restores, portability is a database and object backfill and DNS switch away. If you want strong durable storage, the Internet Archive has Vault, a product that can act as long term storage of last resort for digital preservation.
Lets Encrypt serves nearly 192M websites with 13 full time staff and an annual budget of approximately $3.35M, for example.
I'm not worried about who owns my data, but I do want to have a stable identity. The first Mastodon server I signed up with mysteriously disappeared after a couple of weeks, so I decided I was better off paying a small monthly fee to put it on my own domain.
And even when you give them an app and basically spoonfeed them with the alternative, the small group that has come before will act like a bunch of elitist NIMBYs who will cry about their small "community losing character".
Because self hosting is a big commitment, costly in time and resources, and just generally a skill that the vast majority of users simply don't have (and they'd be well advised not to bother). There are a few managed mastodon services for this that I've been eyeing for corporate usage as I can see the moment coming that we'd might to be on mastodon at least as Twitter/X has been imploding a bit lately. I could probably figure out self hosting but I have more urgent things to do.
I think fediverse offers a decent compromise here which is that people can self-host an instance for other people to use. Some of the longest running instances have a few hundred users or maybe a thousand. So if one in 300 people is interested in self-hosting then they can support the other people who either don't have the skills or don't have the interest. It's not perfect but it's working pretty well for those servers.
>How can we make more people self host their data rather than giving it to corporations?
Here's my pitch...
Sell a productized version of a server that has everything you need to run all of your data-sharing needs already set up with a nice front end that can be operated by a remote control from an HDMI-connected TV. Using that front end, the user connects to the local network, establishes mobile app companions, enters in any global details for accounts they want to maintain, and manages all the configuration options for the server.
The server would host all of the things a household would want to maintain, using open source projects for transparency and maintainability. That would include things like peertube and mastadon for publishing content and media, but it would also include home automation software, as well as personal media software like owncloud as a way to replace google drive content and plex to manage personal media playback.
Basically, a little server that uses open-source software to emulate every modern cloud-based service, on a household scale so that you can run it cheaply enough to be affordable ($60-$70 bucks?), layered in encryption and firewalls for privacy and federated to other home servers (and everywhere else) using the fediverse, while also adding in anything you would want a home-management or home media server to do.
I call it an "accent server". Like an "accent table". I would make it stylish enough to display, but discreet enough to tuck out of sight.
And, personally, I see this kind of thing coming around either way. It's just a matter of whether or not one company puts together all of this software and starts offering it as a walled garden, or if it bumbles itself together out of CLI utility chaining, and enough reddit posts circling around the same setup questions.
That assumption is based on the idea that most people seem to want what this would provide; it's just that not even particularly tech-minded people want to go through the steps of setting each of all of these things up. And it's only when you have 3 or 4 of the services or features working in tandem that they add up enough to make a change in lifestyle (which is what we're attempting) tempting enough.
So if you could put together a "buy it once, plug it in, set it up, forget about it" kind of offering, I think you would get a ton of people that would buy it, and then once it was just a thing in your house that you could start adding custom plugins to (as easy as installing an app), then you would get a ton of adoption. The hard part is marketing; you have to really explain it fully to make anyone understand what it is you're trying to offer.
I can't count how many hacker conventions over the past 15-20 years I've been to where someone was evangelizing a product that claims to do what you're talking about. So many of these "dead simple" "plug and play" devices. Rarely do they survive more than a year or two before those involved lose interest or give up. They have a very hard time finding a product-market fit in a market of technophiles. They never even come close to a market of normies.
- The raw idea seems easy.
- The initial implementation seems like it should be of moderate difficulty, but is actually very challenging to get even close to right.
- The long term maintenance is a nightmare, but don't worry, you won't survive long enough to worry about that.
- The infrastructure and policy implications of getting and keeping it connected to everyone else are intractable. (See https://news.ycombinator.com/item?id=38531969 for some tip-of-the-iceberg examples.)
Yeah, as someone interested in this kind of thing, I've been hoping someone else would put something together that would work, but I think I share your assumption that this is probably not something that can be made into a product profitable enough to finance a company on.
I will say that, for the most part, these companies try a kind of "lock you in to our product which uses open source" scheme that could never possibly work. And, further, that no one has ever implemented the kind of system that I have in mind that I've seen. But that's not because it's unique or complex, just that it isn't a good path to a minimum viable product, so it isn't a good way to spin up a company quickly.
But yeah; aside from burning through cash in order to build enough coverage (maybe a year of dev just on this; no product dev yet) for a product that you will never actually profit from, I don't see how anyone could bring something like this to market.
All of that aside, a product that can sustain a company is not the only way to have a product exist. Modular productization and loss leading are a couple of ways to envision this. But I'm betting some kind of fractional componentization starts happening that makes this kind of stuff more maintainable. YMMV, though!
This actually seems like a great use-case for FOSS. Lots of people have tried their hand at this, so why don't we all put a little effort in to get it done?
Obviously then it won’t. It’s like asking how is a YouTube video going to work if YouTube the entity stops hosting it.
Honestly, the peer tube method of storing media is actually kinda nice. Not everything needs to live forever, and it brings back a semblance of privacy.
On the other hand of this, larger companies can pin smaller videos on other instances while supplementing with their own ad supported videos.
You can follow other servers and help to spread the load. You can decide how much of your space you want to use for that and which strategy you want to use to cache other peoples servers (new videos, most watched, hot, etc.)
My problem with fediverse is that is not that well connected. There are some mastodon instances, but I am not sure if you are a user on one instance you have access to other instance.
I am not sure if we have fediverse, or if we have isolated siloses.
I see people repeatedly misunderstand this aspect unfortunately, because it's hurting the adoption. It has no effect what instance you are on, you are all on Activity Pub. You can join any instance you want and it will be no different from joining any other instance. You can interact with anyone on any instance. This is just like how you only need to know my Email address to send me a message, you do not need to also use the same Email provider as me.
As you can see, the bigger server 50% more posts, 40% more participants, 25% more posts today.
As you surf your "local server", you don't get "everything" from the Fediverse. If you care about that, you likely want to join the "biggest" server you can.
Personally I don't care too much about this. There's more content added to the Fediverse than I have time to consume, and so seeing a slice based on who I currently follow and the server I utilize is plenty for me.
But it also makes sense if it bothers people who don't want to miss out on some zeitgeist.
There are incredibly important differences in user experience when picking one instance over the other.
A very small one has a large likelihood to disappear. Each instance has different moderation rules. On a small instance, you don't even see entire threads and lots of other stuff does not sync properly.
In general, yes, a user on any mastodon instance can access any other - they are not siloed.
Even further: a user on a mastodon instance can see & interact with posts on Lemmy (the Reddit alternative), pics on Pixelfed (=Instagram), videos on Peertube (=Youtube), and content from a long list of other services, all from their single mastodon instance.
(There are exceptions, e.g. you could run a siloed internal company mastodon, and notably server administrators are able to block other servers entirely - but as a user you can always choose a server that federates as widely as you'd like, and if you self-host you're unlikely to block or be blocked by anybody)
> There are some mastodon instances, but I am not sure if you are a user on one instance you have access to other instance.
_In general_ you may assume probably yes. Caveats are if one of the users instances blocks the other one's instances (in practice, rare) or if one or both instances doesn't federate at all (Truth Social and Gab are the big examples of this).
If your instance on which the user is on or the other one blocks that instance you will not have access.
The user identity is an issue on the fediverse and it is know by the creators of ActivityPub. There are plans to create a way for global identities which will solve many of these issues.
I think what you're describing IS activitypub. The major issue is that each implementor has a preferred message type and only basic functionality of the others. I've posted this elsewhere in the thread, but Lemmy top-level posts are implemented as Pages and communities are implemented as Groups. Currently Mastodon has implemented both but with limited functionality. There is a rework of Groups that is listed as in-progress on the roadmap (https://joinmastodon.org/roadmap).
I think the way we ended up in this situation is that there are quite a few types of messages in the AP protocol, and up until recently the up and coming ones were seeing pretty limited use. Without another service to test against, I can understand why a lot of fediverse developers have opted to kick that can down the road. That said, we are definitely in the era of determining the defacto use case for each of these message abstractions, and I suspect that will be a slow process and involve a lot of back and forth between projects.
Because if the dev wants to fix the site for your browser, knowing what browser to target is absolutely essential.
In this case, it sounds like the devs specifically targeted Safari to not be supported. You could try to get around this with a user agent spoof, though.
I like your music by the way (Hoggatah)!