We're pleased to announce the completion of the beta program for Mitra. This app has undergone several months of testing by our in-house staff and beta testing customers.
What is Mitra?
Mitra is a Fediverse enabled social networking application built on Rust and PostgreSQL. Learn more about Mitra at Codeberg.
We're pleased to announce the completion of the beta program for Mitra. This app has undergone several months of testing by our in-house staff and beta testing customers.
I fixed proof.verificationMethod values in examples, as well as accompanying text. These values should include fragments that identify a specific key in a DID document, so they are not actually DIDs but DID URLs (a similar change was made in FEP-8b32).
I also added a paragraph on authentication and authorization (with a normative reference to FEP-c7d3), and described WebFinger address reverse discovery in compatibility mode.
I fixed proof.verificationMethod values in examples, as well as accompanying text. These values should include fragments that identify a specific key in a DID document, so they are not actually DIDs but DID URLs (a similar change was made in FEP-8b32).
I also added a paragraph on authentication and authorization (with a normative reference to FEP-c7d3), and described WebFinger address reverse discovery in compatibility mode.
The Social Web Foundation is such a disgrace. One of the most flagrant attempts to co-opt a grassroots movement I've ever seen.
But on the other hand, naming it like that is an interesting move. I'm enjoying watching how all those Bluesky and Nostr shills, who were trying to re-define "Fediverse" for years, are finally getting a taste of their own medicine.
Fedify, an ActivityPub framework, has finally released its first stable version, 1.0.0! Here are key changes:
Deprecation of the term handle
From this version, the term handle across Fedify will only be used to refer to fediverse handles (e.g., @hongminhee@fosstodon.org). An actor's internal unique ID (e.g., b379dbdc-3b4f-4ef4-88c2-fc25632d1c22) is referred to as an identifier, and the WebFinger name (e.g., hongminhee) is referred to as a username.
The term handle in the API will be maintained for a while for backward compatibility, but deprecation warnings will be logged, and it is planned to be removed in the future.
Linked Data Signatures is an outdated standard, but it's still relied upon by major fediverse implementations such as Mastodon.
In addition to HTTP Signatures and Object Integrity Proofs, Fedify now supports Linked Data Signatures from this version, thus supporting all types of signature methods used in the fediverse. This makes Fedify an ActivityPub implementation with the best interoperability.
However, Fedify users don't need to do anything special to use Linked Data Signatures. If an incoming activity has Linked Data Signatures, it automatically verifies the signature, and all outgoing activities will have signatures in three formats: HTTP Signatures, Linked Data Signatures, and Object Integrity Proofs.
From this version, you can forward activities received in the inbox to other actors using the InboxContext.forwardActivity() method.
At first glance, you might think that you could just resend an activity received in the inbox using the Context.sendActivity() method. However, if you do this, the original signature is removed before the activity is delivered to the inbox, and when sending it, the signature of the forwarding actor is attached instead, causing the receiving side of the forwarded activity to not trust it.
On the other hand, when using the InboxContext.forwardActivity() method, the activity is forwarded with the original signature preserved, avoiding this problem. (Of course, the original activity itself must be signed with Linked Data Signatures or Object Integrity Proofs.)
Sending Delete(Application) on fedify inbox termination
From this version, fedify inbox will send a Delete(Application) activity to all peer servers it encountered when terminated. This is typically an activity sent when deleting an account, which will help prevent residual data related to temporary actors from remaining on other servers.
PostgreSQL drivers
The @fedify/postgres package, which implements PostgreSQL drivers for the KvStore and MessageQueue interfaces, has been released alongside this version.
The PostgreSQL driver is a backend that can be sufficiently used in production, especially recommended for projects already using PostgreSQL.
Additionally, an option to select the PostgreSQL driver has been added to the fedify init command.
Celebrating Fedify 1.0.0
With the release of version 1.0.0, Fedify will now maintain API backward compatibility as much as possible. (Of course, in the long term, there may be a 2.0.0 that breaks backward compatibility.) This should be good news for those who have been hesitant to use Fedify because there hasn't been a stable version until now!
So, hoping that more services will support ActivityPub in the future, I conclude this post!
Fedify, an ActivityPub framework, has finally released its first stable version, 1.0.0! Here are key changes:
Deprecation of the term handle
From this version, the term handle across Fedify will only be used to refer to fediverse handles (e.g., @hongminhee@fosstodon.org). An actor's internal unique ID (e.g., b379dbdc-3b4f-4ef4-88c2-fc25632d1c22) is referred to as an identifier, and the WebFinger name (e.g., hongminhee) is referred to as a username.
I like listening to people chatting in streaming and podcasts, so I'm making a federated chat platform called Hamabē. Yes, it's FOSS.
Hamabē is a successor of Audon, but a new platform speaking ActivityPub and independent of Mastodon API.
(Thank you @namekuji for letting me take the project over and kindly hosting my infra!)
You can follow Hamabē accounts from AP platforms and can receive notifications when a space starts (if your platform supports Event activity)
Right now Hamabē only has voice chat (along with simple text chat) to cover Audon's use cases, but there's a plan to add text-based group chat later.
Some basic features have been implemented, but it's still in very early stage and documentations are not ready yet. Issues and PRs are also closed for now, but I'll open them once it reaches first alpha release. :abunhdhappyhop:
I like listening to people chatting in streaming and podcasts, so I'm making a federated chat platform called Hamabē. Yes, it's FOSS.
Hamabē is a successor of Audon, but a new platform speaking ActivityPub and independent of Mastodon API.
(Thank you @namekuji for letting me take the project over and kindly hosting my infra!)
Between FediForum and now the Social Web Foundation I'm very tired of seeing these intensely corporate initiatives in this space where the majority of projects are entirely volunteer (or grant supported) efforts
- Editing a category now issues an Update(Actor)
- replies is now populated and responds with an OrderedCollection of direct replies (see the post about that)
- Proper sharedInbox support
- Better indicators for content that comes from non-local (aka "remote") users
- Conversational context synchronization mechanic (corresponding post for that)
- Moving a topic out of the "uncategorized" category will now federate out an Announce
By and large most incompatibilties have been resolved, although if you do find some issues, please do let me know in the corresponding bug report thread.
I'm looking to wrap up the year with some of the more difficult projects I've put off
- Object Integrity Proofs, which will also enable Inbox Forwarding
- Better handling of "Open in App" signals from third-party instances
- Post visibility support (or at least better handling so non-public messages aren'y unceremoniously dropped!)
- Ongoing integration with FEPs 400e and 7888
This code was originally a part of Mitra, but over time I moved re-usable functions into independent packages and then started using them in other projects, Activity Connect and fep-ae97-client. Compared to activitypub-federation-rust, it is a low-level library with fewer dependencies, suitable for both servers and clients. The key feature is support for nomadic identity.
Currently there's no documentation and API is not well designed, but I will be improving it. The license is AGPL-3.0
This code was originally a part of Mitra, but over time I moved re-usable functions into independent packages and then started using them in other projects, Activity Connect and fep-ae97-client. Compared to activitypub-federation-rust, it is a low-level library with fewer dependencies, suitable for both servers and clients. The key feature is support for nomadic identity.
- Custom feeds (aka lists / antennas). To add a custom feed, navigate to your profile and select "View custom feeds" in dropdown menu. Currently all custom feeds are "exclusive": posts that appear in a custom feed are not displayed in the home timeline.
- Include liked posts and posts where current user is mentioned in full text search results.
- FEP-e232 is enabled by default (this means quote posts will not reach people on Pleroma <2.6.0)
- "👎" reaction is federated as Dislike activity, which is processed by Lemmy as downvote
- Custom feeds (aka lists / antennas). To add a custom feed, navigate to your profile and select "View custom feeds" in dropdown menu. Currently all custom feeds are "exclusive": posts that appear in a custom feed are not displayed in the home timeline.
- Include liked posts and posts where current user is mentioned in full text search results.
- FEP-e232 is enabled...
Im really happy to see another large scale MLS deployment. It shows the technology is fit for purpose.
Discord uses MLS for key negotiation in group calls with really fine-grained Forward Secrecy and Post-Compromise Security: A new member of the group cannot decrypt any media sent in the previous epochs, and a leaving member of the group cannot decrypt any media sent in future epochs.
Im really happy to see another large scale MLS deployment. It shows the technology is fit for purpose.
Discord uses MLS for key negotiation in group calls with really fine-grained Forward Secrecy and Post-Compromise Security: A new member of the group cannot decrypt any media sent in the previous epochs, and a leaving member of the group cannot decrypt any media sent in future epochs.
Despite this being promoted as supporting multiple "discovery providers", the text says »This will specify how an instance will “feed” content to a discovery provider to index. And how a discovery provider can be queried to actually search and discover content.«
Nothing is being said about why there would ever be a need for a more than a few big providers, once it is established that the big ones "work". As usual, centralization is looming here, by a few corps "generously" offering high-speed "discovery" for "free".
Also, nothing is said about providers sharing results of the indexing, to enable fediverse-wide search - instead, the proposal almost inevitably points to few providers that everybody needs to feed if they want posts to be found.
"Hope" will not change that hence just saying »We want to specify how a discovery provider works and interfaces with a Fediverse server instance. We hope to inspire several competing implementations of the specification.« does not make much sense.
Nothing is said about who outside of the Fediverse gets to query a provider, or to process the data that has been extracted from a fediverse server feed - and for which purposes. It's even expressly mentioned that »These “providers” might serve other purposes than just search and discovery«
»The protocols and implementations will respect user privacy«, but the text only offers "shoulds":
-
»Our reference implementation will respect this setting and only ingest content from creators who opted in to discovery in the first place.« (note the telling words "respect" and "ingest" here, it does not even seem consensus that providers are "fed" by Fediverse servers).
-
»All other information a discovery provider gathers should be anonymous.« Should?
-
»Fediverse Discovery Providers should only ever index content clearly marked as “public”.« Should?
-
»Fediverse Discovery Providers should honor these settings and only index user data and content from users who have opted-into that.« Should?
Another red flag: »This means we might not always be able to incorporate all the feedback we get into the very first draft of everything we publish. But rest assured that we are committed to continue working on this even after this first project has ended, so we will be able to make adjustments later on.«
More privacy after the first implementation is out? And no: With Mastodon gGmbH being the driver of this, and with the current wording, we can not "rest assured".
Despite this being promoted as supporting multiple "discovery providers", the text says »This will specify how an instance will “feed” content to a discovery provider to index. And how a discovery provider can be queried to actually search and discover content.«
Nothing is being said about why there would ever be a need for a more than a few big providers, once it is established that the big ones "work". As usual, centralization is looming here, by a few corps "generously" offering...
@katzenberger
"Nothing is said about who outside of the Fediverse gets to query a provider, or to process the data that has been extracted from a fediverse server feed - and for which purposes."
The fact that the referenced passage links to a blog post about third-party data collection and algorithmic contraband media detection might provide a clue
A small compendium of the Fediverse platforms I use/know well.
In the past few days, I revisited some of my old Fediverse instances since some friends asked me to help them set up a new one. I also took the chance to perform maintenance on some leftover instances. Here's my experience:
Akkoma: My oldest instance still running, opened in 2022. It was offline for a few months (3/4). I updated everything to the latest version and restarted it. I’m not sure why, but it’s extremely slow, with a heavy load on Postgres and many queries just to open the main page. I like Akkoma - I'll investigate further.
GoToSocial: I updated a friend's instance - GoToSocial itself was up-to-date, but the underlying system wasn’t. I noticed that once it exceeds 2000 followings, it becomes a bit slow. The database is PostgreSQL, but that's not the issue. The GoToSocial process becomes somewhat heavy on the VPS. Still, it's very usable and a software with great potential, in my opinion. The Mastodon API is implemented quite well and works with the major software.
Mitra: It seems well-built. The person had around 1000 followers and followings on a Mastodon account, which they moved from a large instance. No speed issues, though sending a message makes the server “heavy” for a bit, but it’s temporary. The Mastodon API is partially implemented, but the software is advancing quickly, and I find its native interface quite pleasant.
Snac2: I've always had a soft spot for Snac2. The lack of a database and some design choices make it an excellent solution for small instances. For example, sending posts to all known instances increases visibility and interaction. Its basic, JavaScript-free interface is very clear, though it might not be the best for those used to Mastodon. But the Mastodon API is improving version by version, and I think the developer is doing an excellent job. It struggles a bit with larger numbers, but that's due to the underlying file system, not the software itself. If "move" support (both in and out) were added, I would recommend it to anyone starting self-hosting for single-user or small community instances because "move" is one of the options that gives the most freedom in Fediverse software.
Mastodon: My “old” personal instance was stuck at version 4.1.x and had been offline for a few months. I updated the FreeBSD Jail and upgraded Mastodon to 4.2.12 and then to 4.3.0-beta1. No issues. I also helped a friend (who had an old Pleroma-based instance they barely used) migrate. This user has around 5000 followers and followings - Mastodon is running on FreeBSD on a VPS (arm64) for just over 3 euros a month, with no significant issues (apart from media storage, but that's not Mastodon’s fault). Mastodon is sometimes said to be heavy, and that's partly true, but its modularity ensures that even in cases of overload, queues may slow down, but navigation and the local timeline remain reasonably fast. I think this is a good thing for any larger-scale use of an instance.
In short, I think things are moving in the right direction, and the software is evolving nicely. Well done, devs!
A small compendium of the Fediverse platforms I use/know well.
In the past few days, I revisited some of my old Fediverse instances since some friends asked me to help them set up a new one. I also took the chance to perform maintenance on some leftover instances. Here's my experience:
Akkoma: My oldest instance still running, opened in 2022. It was offline for a few months (3/4). I updated everything to the latest version and restarted it. I’m not sure why, but it’s extremely slow, with a heavy...
By far my favourite option. Without snac2 and the ability to self-host it very easily, I would not be on the Fediverse today. Bonus points for the main developer being very easy to get in touch with, and very reactive when problems are reported.
Keeping in mind that I am not coming from Mastodon or Twitter. Snac2 is my first experience as an active contributor to the Fediverse and more generally to micro-blogging.
I've always had a soft spot for Snac2.
By far my favourite option. Without snac2 and the ability to self-host it very easily, I would not be on the Fediverse today. Bonus points for the main developer being very easy to get in touch with, and very reactive when problems are reported.
📝 Latest from @jonah on the blog: Proton Wallet Review
"Proton, the Swiss creators of privacy-focused products like Proton Mail and ProtonVPN, recently released the latest product in their ever-growing lineup: Proton Wallet..."
@privacyguides@jonah I share most of the scepticism and must say I don't expect much additional value by Proton Wallet.
As described, it is useful for existing Bitcoins, so me tinkering with getting a cold wallet for purchasing at @njalla may now find instead a place on Proton Wallet.
Besides that, I agree Proton Wallet might become extremely useful for temporary credit cards and as Google Pay alternative; though I cannot evaluate the barrier for entry in that matter. :BlobhajBlanketBlue:
@privacyguides@jonah I don’t understand why Proton keeps releasing *new* things, while their existing products still have many issues.
For example, I’ve been using Proton Mail for years, the app on iOS is just terrible. It’s buggy and lacks basic features all other e-mail apps have.
You can’t even zoom text properly, or set a notification for specific users / threads, etc. etc. etc.
Hoping the quality will improve, i’d love to come back when that happens.
@privacyguides@jonah I do agree with your sentiments and was stunned when they announced this out of the blue. But again, I kinda felt similarly about Proton Pass when they launched it and wondered why they bothered when we had Bitwarden. Proton Pass offered nothing substantial over the competition, but it eventually grew to become a very solid password manager. So I’m currently on the “wait and see” bench.
Reply Collections have not yet really reached the centre of the #Fediverse. Among other things, moderation aspects play a role here (see FEP-7458 or FEP-5624). But in principle, they offer a wonderful opportunity to maintain consistency in discussion threads in the Fediverse.
Smaller instances in particular often lack reactions to content published in the Fediverse. In principle, this is not a bad thing. Nevertheless, it makes sense for both servers and clients to be able to retrieve a complete comment tree in some scenarios (possibly at the request of a user).
To this end, we have submitted a first draft in a pull request to the Upstream #ActivityPub plugin for #WordPress. In this case, we benefit from the already existing comment management of the WordPress core and only list approved comments in the replies collection.
Reply Collections have not yet really reached the centre of the #Fediverse. Among other things, moderation aspects play a role here (see FEP-7458 or FEP-5624). But in principle, they offer a wonderful opportunity to maintain consistency in discussion threads in the Fediverse.
Smaller instances in particular often lack reactions to content published in the Fediverse. In principle, this is not a bad thing. Nevertheless, it makes sense for both servers and clients to be able to retrieve...
How many domain names your government needs to block in order to censor an entire network?
Bluesky: 1 domain name
Nostr: 680 domain names, but blocking 10 most popular relays and hosted clients would probably be enough to kill it
Fediverse: more than 20000 domain names
>you should be able to ask your most passionate followers to support you with a premium subscription.
>That's a promise not available on the Fediverse ...until now.
>not available
>you should be able to ask your most passionate followers to support you with a premium subscription.
>That's a promise not available on the Fediverse ...until now.
>not available
might be time to remove the "experimental" qualifier for wizard.casa
We have been running nightly backups to BackBlaze B2 for about a week now and things seem to be going well and I plan to keep this going. Next month it will be 2 years running this Mitra instance :aru_0510:
Gregory's Server
