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.
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.
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.
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.
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.