@iwojima It removes all data associated with the user. Posts, likes, follows - everything. If the user is local, it should also send a Delete activity to his followers and follows
@rafael_xmr@monero Support for portable objects can be added to existing Fediverse applications, the idea is relatively simple. However, implementing it might still require significant effort because of the fundamental shift from "one account -> one server" to "one account -> multiple servers". I've started to work on this in Mitra, but we're still several months away (at the very least) from anything usable.
Once this idea is proven to work, I expect rational developers to adopt it, because the benefits of data portability seem to vastly outweigh its downsides.
>So we provide the entire activity as the object of the Add activity, signed with identity proofs, just as we used to do with LD-signatures
Do you mean integrity proofs (as in FEP-8b32)? Identity proofs (as in FEP-c390) serve a different purpose, and while they can be added to activities too, I don't understand how the recipient can use them to verify the object of Add activity.
@frogzone@nimda@aura Ethereum wallet login doesn't require a blockchain node, only a browser extension. But I'm not a fan of it either anymore, and in Mitra versions 2.0 and newer it is disabled by default. Ethereum payment processor is not used by anyone (and also disabled by default).
You can see the list of instances here: https://mitra.fediverse.observer/list I haven't seen any canadian ones, but IIRC @parker once said that he might be interested in trying Mitra
>Due to insufficient origin validation in all Mastodon, attackers can impersonate and take over any remote account.
A similar vulnerability was discovered and closed in Mitra. As far as I know, takeover is not possible here, only impersonation, but still it can be quite bad. Update to v2.8.0 if you haven't already
@iwojima I'm not really sure if this reasoning applies to ActivityPub world where peers are discovered automatically.
When Mitra encounters a new actor, its home server is added to the "instance" database table. If you don't want that, you can switch to allowlist federation.
Client API endpoints that require authorization are protected with OAuth
@monero@rafael_xmr I know how Nostr works, I just don't think it is better. However, if it still be around in a year or two, I might consider using Nostr relays for storing AP data. Why not, if this infrastructure already exists
@rafael_xmr@monero With AP you can have multiple admins too. Server-bound accounts is not an inherent limitation of a protocol, it just happened that popular servers like Mastodon and Lemmy are designed this way.
Developer of ActivityPub-based micro-blogging and content subscription platform Mitra. Working on Fediverse standards: https://codeberg.org/silverpill/feps