This, they should make a cool software with a cool name, like "Pleroma".
HN user
lainsoykaf
I did pleroma
What would they compensate for?
This can't work because it just raises the efficiency of mining. That means mining will become cheaper. That means your reward is higher. That means you can mine more for the same money. That means every miner does that, increasing the part of the heat that's wasted.
In the end, the exact same amount will be 'wasted' as before.
ah, sorry, pleroma :)
Gargron wrote one: https://blog.joinmastodon.org/2018/06/how-to-implement-a-bas...
We started doing OTP releases in Pleroma for this reason: https://docs-develop.pleroma.social/backend/installation/otp...
I run a matrix server myself and can not really recommend doing so. It takes a lot of resources and the way e2ee is done is at least questionable.
We have more fine grained moderation tools, but they are more complicated. We're making it easier in our admin frontend all the time, though.
Don't forget the chat system, soon to be released :)
We're also working on making it easier to install and switch between frontends.
ActivityPub can be used in a P2P situation. The biggest problem for that right now is that we use DNS for finding other instances, so you will need something with a domain name.
If I create an account on a Mastodon instance, and want to move it to another instance, do I lose everything?
You can send a `Move` activity that will tell other instances that you moved, so people will (depending on their server) refollow you automatically. We (= people working on ActivityPub systems) are thinking about ways to create identities that don't belong to any one server, so you wouldn't lose your account even if your server went down.
And how does integration among the various platforms currently out (e.g., Mastodon, Plume, Pixelfed, etc) actually work? Is there some tool to see feeds aggregated from all these implementations? Or does it work differently?
In general, systems display what they can. Pixelfed, Mastodon and Plume mostly send `Note`s and `Article`s around, which are easy to display in any of their respective interfaces. Other types like `Video`s will usually be displayed as good as possible, with a link to the originating instance. Unknown activities are usually just thrown away by the receiving server.
It's no feasible, we use a lot of postgres specific features. Pleroma with postgres runs fine even on Raspi 2.
This is sadly not quite correct. You can send out a 'Move' activity from your old account, notifying other servers that you have moved. There's no guarantee that they understand that activity, or, if they understand it, that they actually follow the new account automatically.
Mastodon.social is sadly one of the worst instances to join. Onboarding / Selecting a good instance is the hardest problem for the fediverse.
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.
regarding data protection, nobody knows.
groups are a very complicated topic, everybody wants them but nobody can agree on what exactly they are. Either way, we are working on them for Pleroma, they are necessary for a lot of other nice features that we want to have in the future. See https://git.pleroma.social/pleroma/pleroma-meta/issues/14
Pleroma has built in support for connection to an xmpp server, to share account data.
We are also working on a proper ActivityPub chat, but this was put on ice for a while because it require Group support for many cases, and that's another complicated topic in a federated world.
Overall, the speed of federation is very good, but we will be releasing a new federation transport over websockets in the next few weeks which should make it realtime in nearly all situations.
nobody properly deals with it yet. We are small enough for now that we can get away with moderation by hand / blocking bad instances.