We Distribute is a community-organized news site which covers the Fediverse. If you like to write about federated social media then you could help to expand their coverage. See the link above for more details.

Ibis is a federated encyclopedia which uses the ActivityPub protocol, just like Mastodon or Lemmy. If you want to start a wiki for a TV series, a videogame, or an open source project then Ibis is for you! You can register on an [existing instance](https://ibis.wiki/explore) or [install it on your own server](https://ibis.wiki/article/Setup_Instructions). Then you can start editing on the topic of your choice, and connect to other Ibis instances for different topics. Federation ensures that articles get mirrored across many servers, and can be read even if the original instance goes down. Ibis is written in Rust and Webassembly, fully open source to make future enshittification impossible. --- This release features a redesigned [explore page](https://ibis.wiki/explore) to browse instances and recently edited articles. Articles now have [federated, nested comments](https://ibis.wiki/article/Main_Page/discussion), as well as more subscription options to get notified about new edits and comments. There are also lots of minor changes and improvements. ### Changelog - New explore page with list of instances which shows the topic, update time and list of recently edited articles - Implement nested comments for articles - Users can subscribe to articles, in order to get notified about new edits and comments - Settings for instance name and topic - Much better error handling - Add HTML title tag for all pages - Icons - Make diff view readable in dark mode (thanks @Earthgames) - Basic about page - Show pending edits which have not federated yet - Various bug fixes The next major version 0.3.0 will include federation with Lemmy, Mastodon and other compatible Fediverse platforms. The plan is to treat each Ibis instance as a community, with articles as posts. This way users on Lemmy and compatible platforms can directly browse, read and comment on wiki articles. To follow Ibis development subscribe to !ibis@lemmy.ml or join the [Matrix chat](https://matrix.to/#/#ibis:matrix.org). Contributions to the [source code](https://github.com/Nutomic/ibis) are more than welcome.

Ibis is a federated encyclopedia which uses the ActivityPub protocol, just like Mastodon or Lemmy. Users can read and edit articles seamlessly across different instances. Federation ensures that articles get mirrored across many servers, and can be read even if the original instance goes down. The software is written in Rust and uses the cutting-edge Leptos framework based on Webassembly. Ibis is fully open source under the AGPL license, to make future enshittification impossible. Checkout [!ibis@lemmy.ml](https://lemmy.ml/c/ibis) for more updates and discussions.

This release contains numerous bug fixes and minor improvements. Thanks to Kalcifer for reporting many of these. - LaTeX formatting is now supported to handle mathematics (thanks Silver-Sorbet) - The editor now has a live preview of rendered markdown - Better layout for edit history - Fixed user links in edit history - Edits are now correctly sorted by date - Removed maximum width for page - Render markdown titles smaller than page title - Disable markdown plugins for url shortening and smartquotes - Resize article edit input based on length [More details and download](https://github.com/Nutomic/ibis/releases/0.1.2)

This release contains numerous bug fixes and minor improvements. Thanks to Kalcifer for reporting many of these. - LaTeX formatting is now supported to handle mathematics (thanks Silver-Sorbet) - The editor now has a live preview of rendered markdown - Better layout for edit history - Fixed user links in edit history - Edits are now correctly sorted by date - Removed maximum width for page - Render markdown titles smaller than page title - Disable markdown plugins for url shortening and smartquotes - Resize article edit input based on length [More details and download](https://github.com/Nutomic/ibis/releases/0.1.2)

We also have documentation to setup the dev environment: https://join-lemmy.org/docs/contributors/02-local-development.html If you have questions, feel free to ask here, in the relevant issue or in [matrix](https://matrix.to/#/#lemmydev:matrix.org).

Which of these code styles do you find preferable? First option using mut with constructor in the beginning: ```rust let mut post_form = PostInsertForm::new( data.name.trim().to_string(), local_user_view.person.id, data.community_id, ); post_form.url = url.map(Into::into); post_form.body = body; post_form.alt_text = data.alt_text.clone(); post_form.nsfw = data.nsfw; post_form.language_id = language_id; ``` Second option without mut and constructor at the end: ```rust let post_form = PostInsertForm { url: url.map(Into::into), body, alt_text: data.alt_text.clone(), nsfw: data.nsfw, language_id, ..PostInsertForm::new( data.name.trim().to_string(), local_user_view.person.id, data.community_id, ) }; ``` You can see the full PR here: https://github.com/LemmyNet/lemmy/pull/5037/files

This library is responsible for federation in Lemmy, and can also be used by other Rust projects.

The new major version of Lemmy is now ready, and we need your help with testing. Most importantly it uses HTTP for API requests now, which is much more efficient than websocket. Additionally Two-factor-auth is supported. There are also countless other improvements and bug fixes. You can register on any of the following servers to start testing, no approval required. You can post to your hearts content to find out if anything is broken. The test instances only federate with each other to avoid affecting production instances with spam. - [Enterprise](https://enterprise.lemmy.ml/) - [Voyager](https://voyager.lemmy.ml/) - [DS](https://ds9.lemmy.ml/) If you encounter any bugs that aren't present in 0.17, open an issue and mention in the title that it happened with a release candicate version. Over the next days we will publish new RC versions to fix bugs that will invariably pop up. Instance admins can try the new version by using Docker images `dessalines/lemmy-ui:0.18.0-rc.2` and `dessalines/lemmy:0.18.0-rc.1`. Make sure that working backups are in place. For production instances its better to wait at least some days for the major issues to be fixed.

I want to announce a new version of the activitypub-federation crate. Over the last weeks I worked on major improvements to the usability and documentation. It now includes an extensive guide on getting started to implement federation from scratch, and also an example project which can directly be deployed to a server and federate with projects like Mastodon. The library takes care of basic functionality like HTTP Signatures, activity sending, and fetching data from other servers. Application developers can focus on the main logic, and treat federation as another form of API. There is no restriction to the content being federated: you can implement a microblogging platform, link aggregator, video hosting site or any other type of social media. The goal is to encapsulate all basic functionality, so that developers can easily implement federation without any prior knowledge. Using this library can help to share core Activitypub logic between different projects, so that the same code doesn’t have to be implemented and maintained separately by each project. This way improvements can benefit everyone. It also encourages the use of effective patterns to make Rust and Activitypub work together. All of this has been proven to work in Lemmy which uses this library and is the biggest Activitypub project written in Rust. https://docs.rs/activitypub_federation

I want to announce a new version of the activitypub-federation crate. Over the last weeks I worked on major improvements to the usability and documentation. It now includes an extensive guide on getting started to implement federation from scratch, and also an example project which can directly be deployed to a server and federate with projects like Mastodon. The library takes care of basic functionality like HTTP Signatures, activity sending, and fetching data from other servers. Application developers can focus on the main logic, and treat federation as another form of API. There is no restriction to the content being federated: you can implement a microblogging platform, link aggregator, video hosting site or any other type of social media. The goal is to encapsulate all basic functionality, so that developers can easily implement federation without any prior knowledge. Using this library can help to share core Activitypub logic between different projects, so that the same code doesn’t have to be implemented and maintained separately by each project. This way improvements can benefit everyone. It also encourages the use of effective patterns to make Rust and Activitypub work together. All of this has been proven to work in Lemmy which uses this library and is the biggest Activitypub project written in Rust. https://docs.rs/activitypub_federation

This standard document explains how group federation works in Lemmy and other projects. It can be useful to developers who want to implement a similar federation model.

Between Lemmy versions v0.8.10 and v0.9.0, we did a major database rewrite, which helped to improve compilation time by around 30% (see below). In this post we are going to explain which methods were effective to speed up Rust compilation for Lemmy, and which werent. ## Compilation time comparison Here is a comparison of debug compilation times for Lemmy. All measurements were done in with Rust 1.47.0, on Manjaro Linux and an AMD Ryzen 5 2600 (6 cores, 12 threads). Results are taken as the average of 5 runs each. | | v0.8.10 | v0.9.0-rc.11| improvement| |-------------|---------|--------------|-----| | Clean build | 195s | 129s | 34% | | Incremental build | 23s | 17s | 26% | ## Build Graph The build graph and statistics can be generated with the following command, which will generate a file `cargo-timing.html`. ```bash cargo +nightly build -Ztimings ``` In our experience, it is really the most useful tool in order to speed up compilation time. There are a few ways to use it: - The table at the bottom shows which crates took longest to compile. You can try disable unused features for slow crates, or remove those dependencies entirely. If your own crates are slow, split them up (see below). - In the bar graph near the top, you can mouse over each crate to see which other crate it has to wait for in order to start compilation. You can try to remove these dependencies, or features that you don't need. ## Splitting code into workspaces This is often tricky to do, but proved to be the most effective way to speed up compilation. At the same time, it helped to better organise our code into independent parts, which will make future maintenance work easier. As a first step, it is enough to split the code into crates which depend on each other linearly, as this is relatively easy and already helps to speed up incremental builds (because only part of the project needs to be recompiled when something is changed). In case you have a particular dependency which takes very long to build, you should take all code which does *not* depend on that dependency, and move it into a separate crate. Then both of them can be built in parallel, reducing the overall build time. Later you can try to reorganise your code so that crates in your project can be compiled in parallel. You can see below how we did that in Lemmy: **Before:**  **After:**  As you can see in the before screenshot, all Lemmy crates are compiled linearly, which takes longer. In the after screenshot, at least some of the database crates are compiled in parallel, which saves time on any computer with multiple CPU cores. [For more details on how to use cargo workspaces, have a look at the documentation](https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html) ## Disabling debug info This is very easy to do, as it only requires putting the following into `Cargo.toml`: ``` [profile.dev] debug = 0 ``` The effect is that debug information isn't included in the binary, which makes the binary much smaller and thus speeds up the build (especially incremental builds). We never use a debugger in our development, so changing this doesn't have any negative effect at all for us. Note that stack traces for crashes still work fine without debug info. [Here it is in the documentation](https://doc.rust-lang.org/cargo/reference/profiles.html#debug) ## Removing dependencies This only had limited success, for the most part. We weren't willing to remove or replace any of our dependencies, because then we would have to remove features, or have a lot of extra work to reimplement things ourselves. However, there is one specific dependency where we could improve compilation time by around 50 seconds. Refactoring the database allowed us to remove diesel's `64-colum-tables` feature. This was especially effective because diesel only has a single crate, and as a result is compiled on a single thread. This resulted in a period of 40 seconds where one thread would compile diesel, while all other threads were idle. There is still room for improvement here, if diesel can be split into multiple, parallel crates. [Lemmy issue with more details](https://github.com/LemmyNet/lemmy/issues/920) With actix we noticed that it includes a compression library by default, which is useless in our case because we use a reverse proxy. Thanks to @robjtede from the actix for making the necessary changes to allow removing that library. In the end the effect was limited however, because the library could be built very early and in parallel to other things, without blocking anything. It should help with compilation on devices with few CPU cores at least. [Issue in the actix-web repo](https://github.com/actix/actix-web/issues/1561) ## Other optimisations `cargo bloat` was commonly recommended in order to find large functions, and split them up. But that didn't help at all in our case, probably because our project is quite large. It might be more useful for smaller projects with less code and less dependencies. It was also suggested to reduce macro usage, but there wasn't much opportunity in our case because diesel uses a lot of macros. We removed a few `derive` statements that weren't needed, but without any noticable effect.