Previewing remote subscription options. Mitra now shows a page with subscription price even if the user is on another instance (but you still need to navigate to another server to make a payment).
Minisign identity proofs use the jcs-eddsa-2022 cryptosuite. The proof generation page has also been improved, and it shows commands that need to be executed.
Continued work on cross-instance payments.
New Gallery page that shows media files attached to posts.
I love this solution from @briar to the problem of how to provide an persistently online experience.
Conventionally, you require a server, which increases the barrier to entry dramatically and puts a hard limit to how decentralized a system can be.
This is a fantastic way of lowering the burden of running a "server", spectacularly well suited to a peer-to-peer app where holepunching is taken care of.
How would we do something similar for HTTP/#ActivityPub?
Payment processor now can handle recurring payments made to the same Monero address. It also should be able to recover if payout transaction fails for some reason.
If I'm peeking into an #ActivityPub instance, show me its preferred UI form.
..on mastodon.social, show me the #Mastodon
UI.
..on calckey.social, show me the #Calckey UI
..on bookwyrm.social, show me the #Bookwyrm UI.
..on mitra.social, show me the #Mitra UI.
..on pixelfed.social, show me the #Pixelfed UI.
(..on bluesky.social, show me the #Bluesky UI.)
Authentication methods are now configurable. For example, "Sign In With Ethereum" option can be removed from the login form.
Added Monero login option (disabled by default). It is similar to Ethereum auth, but adapted to work with Monero wallets (although without browser extension the process is not very convenient). The implementation is based on CAIP-122 standard.
@silverpill
Whatever it's origins, don't you think it's best to use open standards? I.e. for #Mitra
Also, it's currency- and ledger-agnostic, at least now. @strypey
i forget who it was that said "a single timeline is unsustainable" (aaron parecki?) but i'm feeling more like the real cardinal sin is publishing to a single profile. i don't mind reading everything in a single view, although making lists certainly helps. it's the publishing that annoys me. i almost never want to send a post to all of my followers. and this goes doubly for replies. i often want to reply within a specific context and only optionally tell my followers about it.
Oh! Not Fedi, strictly speaking, but there is "Circles" - (circu.li). It's s matrix thing and I've been following progress, but lost enthusiasm when i brought up gplus (old hat here as well) and they said "recursive circles were to hard for them to implement".
Then, what's three point I thought. That's where the power of Circles really comes into play.
Did you see that IMDb thing that guys doing with his #Mitra fork yet? He's gonna keep it a softfork too.
I'm pretty sure that the #Fediverse is one of the first social networks I've been on that didn't ever ask me to betray any of the people in my address book.
#Mitra can now process Move() activities.
This activity tells your followers to un-follow your old account and follow your new account when you're migrating from one instance to another. Mastodon can do that: https://docs.joinmastodon.org/user/moving/. I was unable to find any documentation or examples, and I've never seen this activity in the wild, so I just copied the logic from Pleroma.
The problem is that Move() activity must be signed by your old instance, and if the server is offline or if you're banned from it, there's no way to send it. To solve this problem, I want to let users sign activities with their own keys, so even if activity was sent from a new instance, it is still can be verified by other instances. There are two things that need to happen to make this possible:
Embedded signatures. Mastodon can create them, but their implementation is not portable. There should be a clean and simple way to sign JSON object, otherwise embedded signatures will never be adopted in Fediverse.
Identity proofs. This is a verifiable link between domain-based account and user's public key identity. Mitra already supports Ethereum identity proofs, and I'm planning to support GPG keys as well.
I've already started to work on signatures, and will create FEPs for each protocol extension (embedded signatures, identity proofs, user-signed move).