Pleroma 2.0: a free, federated social networking server built on open protocols

Pleroma v2.0.0[1] lets you hover over the "Reply to" text to get the replied to status in a little popup (which might be new in v2.) But also a little "popout" icon that will open the entire thread in another window (which previously existed pre-v2.)

[1] running as essentially a single-user instance.

I started that project, but haven’t had time yet to finish it:

https://git.eeqj.de/sneak/feta

Why is being different a flaw?

> Doing so costs you all of your followers

This is not true anymore. You can "transfer" your account to another instance, and all the followers will not need to refollow.

I would love if social media platforms could stop letting people know who followed who, even to the followers themselves... I think it would make places less vain and toxic

Not quite. It's not a bug, it's a feature.

Going back to the original quote: "The fediverse is like interconnected villages instead of a large metropole. There's no need to shout." and I think it's quite apt.

The fediverse is far closer to early online fora, bulletin boards then it is to e-mail. Maybe you were deeply entrenched in a particular online community, establishing an online identity, a reputation, visibility,... connected to your name. But outside of that domain? Well, you have little social credit on other discussion boards.

This approach models closely to how societies work in reality. And how individuals prioritize their own social connections. First family, then extended family, friends, co-workers, and society at large - an online audience - way down the road. Each of us will subconsciously look at people starting from the implicit question "Who is part of my tribe, who's an outsider?"

Now, the important part here is that you may feel compelled or forced to leave a group, family, tribe,... So, this implies giving up your locally established social credit and hope you can rebuild that elsewhere. For most people, that's an extremely expensive and risky proposition.

So, what do Reddit and Facebook do different, then?

Reddit is hugely successful because it provides a platform that can sustain thousands of small communities. Much like how online fora - but also e-mail based newsgroups or BBS'es - used to work in earlier days. Facebook's killer app is not the wall or your profile - contrary to what you may think - but... facebook groups. The same is true for Telegram or WhatsApp. These are tools that allow you to establish small communities.

And then you have the entire "followers/following" thing.

What Facebook and Reddit did was successfully merge the idea of a portable, persistent identity - a profile - between local communities by building a platform that also made migration and establishing new communities really easy and cheap (just a few clicks: bam! new group or subreddit!)

Now, followers / following: that's NOT a social network. That's an audience. And there's a distinct difference between those two. (even though there's an overlap too)

For all the talk over "engagement", communicating towards an audience is mostly a one-to-many one-way street. You may reach hundreds of thousands on Twitter, but you may only directly engage - and establish a meaningful relationship - with a handful of people.

If you want to directly and presently reach a large audience, then either e-mail newsgroups, the fediverse or online fora are the wrong venues. Arguably, even Reddit is the wrong platform if you directly tap into millions from a single or a few publishing points (accounts).

If you're looking for small communities in which you want to get entrenched, then the fediverse is the right place to be. Even though that comes with the perpetual yet very real trade off of establishing social credit locally which you can never carry with you if you migrate away.

fediverse.network contains fairly exhaustive lists of open registration instances for both pleroma and mastodon

It's pretty much fire-and-forget. I know a bunch of non-technical people who are running Pleroma instances: you don't have to worry about it that much.

Pleroma is built using Elixir + Phoenix (iirc), which has excellent Postgres support with Ecto. That could have been a design decision. Postgres also supports some features SQLite doesn't, such as array types. For certain applications (such as tagged imageboards, boorus), that makes anything but Postgres nearly a non-starter. SQLite data type storage can also be a concern.

Chances are, if you have a server capable of running the Elixir + web framework stack, storage space for cached images, and a proxying web server, Postgres probably isn't much of an overhead on top of that.

Bare in mind that each fedi instance dosen't only host the content generated by users, but also whatever content they repeat/reply to. The fact it needs to be stored (or cached) is one reason why there's so much blocklisting/defederation - because people may not want to host certain content from instances known to commonly host it. It may even store more from the public timeline (I'm not sure about the specifics of Pleroma). Nevertheless, even with five users, you can fill up quite a lot of space in a database and on the filesystem.

We do provide a step-by-step guide, which also involves installing postgres. In general, I think installing Elixir and Erlang is the much scarier part for most people, because few people have ever used them.

Sadly, we can't just use SQLite because we use Postgres-only features like jsonb extensively.

You’re not entirely incorrect, but you’re not being kind, either.

Really all we’re talking about here is whether or not the thing that writes the files is in-process or an adjacent process.

If they can manage to run Pleroma, they can manage to run a Postgres beside it. I think the hurdle you are describing is to self-hosting anything in general. Standing up a self-hosted postgres is actually easier/simpler/better supported than some random weird elixir app.

I think standing up pretty much ANY type of server might be a non-starter for 99% of the audience...But then proper documentation would resolve that. In the case of pleroma, the database stuff is simpler, while the elixir and erlang stuff is what is dark magic...though that could be because my background is mostly LAMP sort of stuff. Thankfully, there is documentation for setting up/administering a pleroma instance, and as with most things, better versions of the documentation will surface more and more as time goes by.

It's sort of a "doomed if you do, doomed if you don't issue". SQLite lowers the barrier to start, but if your community grows even modestly then you'll be facing a very scary database migration (or at least scary for small admin teams).

I suspect a soft fork or subversion targeted towards small instances might be more sustainable, but that obviously requires more developers to build and maintain that.

I don't have anything against either furries or sex workers being there, just that between this and half of the public feed being in languages other than English the "what is this all about ?" experience is rather deterring.

Two basic things they could do is add some categorization and have users opt-in to topics for their public feed and limit the posts shown to English plus the languages that can be deduced from the user-agent data - it is after all one of the few legitimate purposes it can be used for.

I was having my 2 cents thought on the topic as well, my conclusion is: A shared blocking list (Or a blockchain system, hehe) can only be used as the last resort.

Systems like such already been developed, for example there is one for Twitter made by third-party called "Twitter Block Chain" (https://github.com/satsukitv/twitter-block-chain).

Yes, it can block "unwanted" posters and bots when a correct list is given, but it could also sometime block innocent accounts when somebody is been mistakenly added to the list (Or that somebody just simply changed their behavior for the better).

For such system to work, the maintainer of the list must be trustworthy, which is the hardest part and almost always falls apart.

Add to the injury, it can also be very hard for others to detect mistakes sneaked into the list, as the list may contains more than 10,000 items, makes it impossible to be completely verified manually.

And what to do if a mistake is indeed discovered? Maintain an unblock list to automatically request the user to unblock? Now user has to maintain their own "Yes I manually blocked this guy" list to counter act the automatic one.

My suggestion is: Yes, you can use a shared block list if there is no other way (The Twitter case). But since Mastadon is open sourced, maybe let's try something else first while still can?

Please give this a little thought: Can a system be designed in such way that makes it really hard for their user to accidentally come across some unwanted posts (without having to block the poster)?

I low-key love that blocking furries is the example here.

I used to be a part of that community and it's got a hell of a poor signal to noise ratio and a major broken-step problem. There are some good ones, but all the others ever seem to want to do is fight.

I'm amazed they can arrange to get out of bed in the morning.

This isn't a problem when choosing who to follow, just with the first impression someone gets of the public feed.

Nobody who you aren’t following can put things into your feed. That’s all the moderation you need; you need not be concerned with the content of the timelines of those you do not follow.

Moderation of one's own feed is not the problem here, the problem is that a community like this is likely to remain perennial if the first impression of it is wierding out the average would-be user.

The problem isn't even that. There's no global account catalog you could search. Thus, you have no way of knowing who of the people you know is on there already. Asking everyone if they know about Mastodon and which instance they're on isn't the answer. I have an idea about making a DHT out of instance servers, but at this point it's purely theoretical. If it does work though, you'll be able to easily import your existing friend lists from centralized services. Could use either their APIs or — better — the GDPR-mandated export feature.

Nope, never started working. I asked kaniini; she suggested extending a particular timeout config value. No values for this worked. I heard this a lot from other people, though I'll acknowledge I shut down my instance a while ago so maybe it's been fixed?

As you are somebody who is responsible for stewarding the ActivityPub specification, I am seriously disappointed by this dismissive attitude.

Imo a screenshot is more useful than people think.

Developers think "well, you see, any number of arbitrary clients can load the data and even impl their own UI features so a screenshot doesn't really make sense because...".

But people mainly want to know what that even looks like at all. Especially with how open-ended "social network" can be. That the screenshots just look like Twitter answers some preliminary questions.