Developing a WebRTC SFU library in Rust

And this year, it starts supporting WHIP.

Rheomesh now supports WebRTC-HTTP Ingestion Protocol(WHIP) and Scalable Video Coding(SVC)

Eventually, this library supports WHEP.

WHEP Support

From 0.8.0, you can use WHEP feature.

Release 0.8.0 · h3poteto/rheomesh

WHEP is a protocol for WebRTC signaling using HTTP for receivers.

WebRTC-HTTP Egress Protocol (WHEP)

In typical WebRTC implementations, you need to implement signaling before starting publishing/subscribing to exchange SDP. Usually, people use WebSocket for it.
However, this can be cumbersome. To support SDP signaling using only HTTP, WHEP is provided. WHIP is for publishing, and WHEP is for subscribing.

Key points are only 3 HTTP endpoints

The publishing process begins with the client accessing an HTTP endpoint and sending an SDP. This is similar to using WebSocket; the client can essentially create an SDP containing the video and audio it wants to send. Sending this to the server initiates the initial stage of publishing.

However, in the case of subscribing, the media information is only on the server side, and with WebSocket, SDP generation was performed on the server side. In fact, most SFU servers send the SDP to the subscriber. Simply providing an HTTP endpoint doesn’t allow the server to unilaterally send data to the client. Therefore, WHEP uses a flow where the client sends an SDP without media information, the server fills in the missing media information, and then sends it back. This allows SDP exchange to begin using a standard HTTP server.

• POST /whep/{session_id}/{publisher_id} — Accepts empty SDP offer from client, returns SDP answer that contains track information specified by publisher_id
• PATCH /whep/{session_id} — Handles trickle ICE candidates
• DELETE /whep/{session_id} — Terminates the session

The session_id is a unique identifier for each publishing session. This is the same as WHIP case. To provide session_id, you need to implement SubscribeTransportProvider:

struct SessionStore {
    sessions: Arc<Mutex<HashMap<String, Session>>>
}

struct Session {
    session_id: String,  // Or user_id.
    subscribe_transport: Arc<SubscribeTransport>
}


#[async_trait::async_trait]
impl SubscribeTransportProvider for SessionStore {
    async fn get_subscribe_transport(
        &self,
        session_id: &str,
    ) -> Result<Arc<SubscribeTransport>, actix_web::Error> {
        let sessions = self.sessions.lock().await;
        if let Some(session) = sessions.get(session_id) {
            let s = session.subscribe_transport.clone();
            Ok(s)
        } else {
            Err(actix_web::error::ErrorNotFound("Session not found"))
        }
    }
}

Architecture

Rheomesh is a WebRTC library, so it doesn’t contain any HTTP servers. This provides a helper method for actix-web.

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let store = SessionStore {
        sessions: Arc::new(Mutex::new(HashMap::new())),
    };
    let store_data = Data::new(store.clone());

    let endpoint = WhepEndpoint::new(store);

    HttpServer::new(move || {
        App::new()
            .app_data(store_data.clone())
            .configure(|cfg| {
                endpoint.clone().configure(cfg);
            })
    })
    .bind("0.0.0.0:4000")?
    .run()
    .await
}

For more details, please refer to the example.

rheomesh/client/example/whep/src/pages/room.tsx at master · h3poteto/rheomesh

Future Plans

Currently, it supports only actix-web web servers. I know it should support other web servers.

Furthermore, WHEP should have protocol extensions, e.g.

• Server Sent Events extension
• Video Layer Selection extension

I want to support them.

And, this applies to both WHIP and WHEP;

• STUN/TURN server configuration
• Authentication and authorization

should be supported.

Developing a WebRTC SFU library in Rust

I’ll share two recent significant updates.

1. Support WebRTC-HTTP Ingestion Protocol(WHIP)
2. Support Scalable Video Coding(SVC)

WHIP Support

From 0.7.0, you can use WHIP feature.

Release 0.7.0 · h3poteto/rheomesh

WHIP is a protocol for WebRTC signaling using HTTP.
https://www.ietf.org/archive/id/draft-ietf-wish-whip-09.html

In typical WebRTC implementations, you need to implement signaling before starting publishing/subscribing to exchange SDP. Usually, people use WebSocket for it.
However, this can be cumbersome. To support SDP signaling using only HTTP, WHIP is provided.

Key points are only 3 HTTP endpoints

WHIP handles only the publish side of WebRTC signaling. The protocol defines three HTTP endpoints:

- POST /whip/{session_id} — Accepts SDP offer from client, returns SDP answer
- PATCH /whip/{session_id} — Handles trickle ICE candidates
- DELETE /whip/{session_id} — Terminates the session

The session_id is a unique identifier for each publishing session. This could be:

- A user ID (e.g., “user123”)
- A stream key (e.g., “live-stream-abc”)
- A room and user combination (e.g., “room1-user456”)

You decide what the session_id represents based on your application’s needs. The session_id is used to:

1. Route the WHIP request to the correct PublishTransport
2. Identify which session to update or terminate

To provide session_id, you need to implement PublishTransportProvider:

struct SessionStore {
    sessions: Arc<Mutex<HashMap<String, Session>>>
}

struct Session {
    session_id: String,  // Or user_id.
    publish_transport: Arc<PublishTransport>
}

#[async_trait]
impl PublishTransportProvider for SessionStore {
    async fn get_publish_transport(
        &self,
        session_id: &str,
    ) -> Result<Arc<PublishTransport>, actix_web::Error> {
        let sessions = self.sessions.lock().await;
        if let Some(session) = sessions.get(session_id) {
            let p = session.publish_transport.clone();
            Ok(p)
        } else {
            Err(actix_web::error::ErrorNotFound("Session not found"))
        }
    }
}

Architecture

Rheomesh is a WebRTC library, so it doesn’t contain any HTTP servers. Usually, users prepare an HTTP server for handling HTTP requests or WebSocket requests. Rheomesh should be called inside their servers, so it doesn’t have its own HTTP servers.

Regarding WHIP, it is the same architecture.
In order to provide HTTP endpoints, Rheomesh provides a method for actix-web. If you call configure method, you can inject WHIP endpoints into your actix web server.

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let store = SessionStore {
        sessions: Arc::new(Mutex::new(HashMap::new())),
    };
    let store_data = Data::new(store.clone());

    let endpoint = WhipEndpoint::new(store);

    HttpServer::new(move || {
        App::new()
            .app_data(store_data.clone())
            .configure(|cfg| {
                endpoint.clone().configure(cfg);
            })
    })
    .bind("0.0.0.0:4000")?
    .run()
    .await
}

For more details, please refer to the official document

https://h3poteto.github.io/rheomesh/pages/05_WHIP/

Future Plans

Currently, it supports only actix-web web servers. I know it should support other web servers.

Furthermore, WHIP is for publish protocol, so we should support WebRTC-HTTP Egress Protocol(WHEP).

SVC Support

From 0.7.1, you can use SVC feature.

Release 0.7.1 · h3poteto/rheomesh

SVC (Scalable Video Coding) is a technique that encodes a single video stream with multiple quality layers (spatial and temporal). Each layer represents different resolutions or frame rates, allowing the SFU to select and forward appropriate layers to each subscriber based on their network conditions. This is more efficient than Simulcast because it requires only one encoding process on the publisher side.

Scalable Video Coding (SVC) Extension for WebRTC

How to use

Publisher side

You should specify encodings in frontend side when publishing a track.

import { SVCEncodings } from "rheomesh";

const publisher = await publishTransport.current!.publish(track, {
  encodings: SVCEncodings(),
  preferredCodec: "AV1",
});

SVCEncodings returns L2T3_KEY for SVC, and you can use this option only AV1 or VP9 codecs. The encodings type is Array<SVCRTCRtpEncodingParameters>, so you can specify any values you want.

encodings: [{ scalabilityMode: "L2T3_KEY" }]

For more details, please refer to the official document

https://h3poteto.github.io/rheomesh/pages/02_getting_started/#publish

Subscriber side

SFU server needs to receive SID and TID parameter for a subscriber. For example: https://github.com/h3poteto/rheomesh/blob/a9a63ef08a995ea7f6b430cc743d3fc7a8d9b748/sfu/examples/media_server.rs#L381-L396

Inside the server, you can set SID and TID for the subscriber.

if let Err(err) = subscriber.set_preferred_layer(sid, tid).await {
    tracing::error!("Failed to set preferred layer: {}", err);
}

After that, this subscriber receives only specified SID and TID packets.

Future Plans

Currently, you have to specify SID and TID fora subscriber. Of course, it is useful for specific cases. For example, you want to show a video widely and minimize other videos.

However, generally, it is annoying to specify SID and TID one by one. So, I’m thinking it would be nice Rheomesh could receive feedback from subscriber’s RTCP and detect the appropriate SID and TID. If we can do it, Rheomesh can change SID and TID automatically depending on the subscriber’s situation.

Developing a WebRTC SFU library in Rust

I’ve recently added a recording function to this project. This update brings new capabilities for capturing and processing RTP streams in flexible, server-friendly manner.

The v0.5.0 release introduces recording features.

Release 0.5.0 · h3poteto/rheomesh

And I published the documentation site. The recording feature is explained on the site.

Recording

Design Philosophy: Raw RTP Packet Forwarding

Rather than creating a monolithic function that handles everything from capture to file generation, I opted for a more modular approach. The recording functionality simply forwards raw RTP packets, leaving encoding and file creation to external tools like FFmpeg or GStreamer.

This design decision prioritizes flexibility, especially for server deployments where different use cases might require different encoding strategies. Both FFmpeg and GStreamer can generate video files from raw RTP packets, making this delegation approach both practical and powerful.

SDP Generation

While the core functionality focuses on packet forwarding, I recognized that Session Description Protocol (SDP) information would be essential for most recording workflows. The library includes SDP generation capabilities, particularly important for FFmpeg-based recording setups.

You can generate SDP strings using the generate_sdp method from the RecordingTransport struct.

Recording Workflow Examples

Using FFmpeg

To start recording with FFmpeg, first generate the SDP file and set up FFmpeg to wait for incoming streams:

$ ffplay -protocol_whitelist file,rtp,udp -analyzeduration 10000000 -probesize 50000000 -f sdp -i stream.sdp

Then, initiate recording using the start_recording method. This begins raw RTP packet transmission, and you should see the video stream in FFplay.

To save the recording to a file instead of just viewing it:

$ ffmpeg -protocol_whitelist file,rtp,udp -i stream.sdp -c copy output.mkv

This command will record the stream directly to output.mkv .

Using GStreamer

For GStreamer users, you’ll need to parse the SDP information and construct an appropriate pipeline. Here’s an example command for H.264 streams:

$ gst-launch-1.0 udpsrc port=30001 ! \
  application/x-rtp,payload=103,encoding-name=H264 ! \
  rtph264depay ! \
  h264parse ! \
  avdec_h264 ! \
  videoconvert ! \
  autovideosink

The specific parameters will vary depending on your encoding format. For detailed information about RTP and parser elements, consult the official GStreamer documentation:

• RTP Documentation
• Video Parsers Documentation

Make sure your pipeline parameters match the encoding specified in the generated SDP.

Try It Yourself

The project includes practical examples to help you get started. Check out the examples section in the documentation.

The camera example demonstrates the recording functionality in action. It displays the generated SDP on screen, which you can copy and use with FFmpeg or GStreamer to receive and process the stream.

What’s Next

Looking ahead, I plan to focus on improving the relay functionality to make the library even more robust and feature-complete.

Motivation

There is a WebRTC protocol implementation in Rust; it is webrtc-rs. This repository provides some examples that include SFU, but we still need to write a lot of code to implement a practical SFU server. In addition, existing repositories implementing SFU servers with webrtc-rs weren’t directly usable for my needs.

Introducing Rheomesh: A Rust SFU SDK

https://github.com/h3poteto/rheomesh

I developed a new SFU library in Rust to build your own WebRTC SFU servers. A key design principle was separating SFU-related logic from signaling protocols. Usually, you need a signaling logic to connect client browsers to your SFU server. I often use WebSocket as the signaling protocol, but, of course, you can choose other protocols, like gRPC or MQTT.

Key features

Key features of this library are

- Rust SDKs for SFU server development
- JavaScript library to communicate with the SFU server
- Supporting relay

It supports:

- Audio and video streaming
- DataChannel
- Simulcast

Nowadays, there is Scalable Video Coding (SVC), but it is not supported yet. Currently, Rheomesh supports only temporal layer filtering and doesn’t support spatial layer filtering due to patent concerns.

An interesting technical challenge during development was implementing a Dependency Descriptor parser. While webrtc-rs provides temporal layer parsing for VP8 and VP9, it lacks support for AV1 and H264, which use Dependency Descriptors for temporal and spatial layer representation.

Getting started

This library doesn’t contain WebSocket server, so please implement a WebSocket server at first, and call Rheomesh methods from it.

Server-side

https://github.com/h3poteto/rheomesh/blob/master/sfu/README.md
First of all, please create a worker and router. Router accommodates multiple transports, and they can communicate with each other. That means transports belonging to the same Router can send/receive their media. Router is like a meeting room.

use rheomesh::config::MediaConfig;
use rheomesh::router::Router;
async fn new() {
 let config = MediaConfig::default();
 let router = Router::new(config);
 let mut config = WebRTCTransportConfig::default();
 config.configuration.ice_servers = vec![RTCIceServer {
 urls: vec!["stun:stun.l.google.com:19302".to_owned()],
 ..Default::default()
 }];
 let publish_transport = router.create_publish_transport(config.clone()).await;
 let subscribe_transport = router.create_subscribe_transport(config.clone()).await;
}

Please call Rheomesh methods in your WebSocket handler.

Regarding publishers:

publish_transport
 .on_ice_candidate(Box::new(move |candidate| {
 let init = candidate.to_json().expect("failed to parse candidate");
 // Send `init` message to the client. The client has to call `addIceCandidate` method with this parameter.
 }))
 .await;
// When you receive RTCIceCandidateInit message from the client.
let _ = publish_transport
 .add_ice_candidate(candidate)
 .await
 .expect("failed to add ICE candidate");
// When you receive offer message from the client.
let answer = publish_transport
 .get_answer(offer)
 .await
 .expect("failed to connect publish_transport");
// Send `answer` message to the client. The client has to call `setAnswer` method.
// Publish
let publisher = publish_transport.publish(track_id).await;

Regarding subscribers:

subscribe_transport
 .on_ice_candidate(Box::new(move |candidate| {
 let init = candidate.to_json().expect("failed to parse candidate");
 // Send `init` message to the client. The client has to call `addIceCandidate` method with this parameter.
 }))
 .await;
subscribe_transport
 .on_negotiation_needed(Box::new(move |offer| {
 // Send `offer` message to the client. The client has to call `setOffer` method.
 }))
// When you receive RTCIceCandidateInit message from the client.
let _ = subscribe_transport
 .add_ice_candidate(candidate)
 .await
 .expect("failed to add ICE candidate");
// Subscribe
let (subscriber, offer) = subscribe_transport
 .subscribe(track_id)
 .await
 .expect("failed to connect subscribe_transport");
// Send `offer` message to the client. The client has to call `setOffer` method.
// When you receive answer message from the client.
let _ = subscribe_transport
 .set_answer(answer)
 .await
 .expect("failed to set answer");

Client-side

https://github.com/h3poteto/rheomesh/blob/master/client/README.md
At first, please initialize transports.

import { PublishTransport } from 'rheomesh'
const peerConnectionConfig: RTCConfiguration = {
 iceServers: [{ urls: "stun:stun.l.google.com:19302" }],
}
const publishTransport = new PublishTransport(peerConnectionConfig)
const subscribeTransport = new SubscribeTransport(peerConnectionConfig)

Regarding publishers:

publishTransport.on("icecandidate", (candidate) => {
 // Send `candidate` to the server. The server has to call `add_ice_candidate` method with this parameter.
})
// When you receive candidateInit message from the server.
publishTransport.addIceCandidate(candidateInit)
// Publish a track.
const stream = await navigator.mediaDevices.getDisplayMedia({
 video: true,
 audio: false,
})
const offer = await publishTransport.publish(stream)
// Send `offer` to the server. The server has to call `get_answer` method with this parameter.
// When you receive answer message from the server.
publishTransport.setAnswer(answer)

Regarding subscribers:

subscribeTransport.on("icecandidate", (candidate) => {
 // Send `candidate` to the server. The server has to call `add_ice_candidate` method with this parameter.
})
// When you receive candidateInit message from the server.
subscribeTransport.addIceCandidate(candidateInit)
// When you receive offer message from the server.
subscribeTransport.setOffer(offer).then((answer) => {
 // Send `answer` to the server. The server has to call `set_answer` method with this parameter.
})
// Subscribe a track.
subscribeTransport.subscribe(publisherId).then((track) => {
 const stream = new MediaStream([track])
 remoteVideo.srcObject = stream
});

Examples

I prepared an example server. Since this flow is complicated, please refer to these examples.

https://github.com/h3poteto/rheomesh/blob/master/sfu/examples/media_server.rs

The corresponding client-side JavaScript code is here.

https://github.com/h3poteto/rheomesh/blob/master/client/example/multiple/src/pages/room.tsx

The Relay Mechanism: A Unique Approach to Load Balancing

One of the library’s key innovations is its relay mechanism — a method for distributing load across SFU servers. I called this relay, but there doesn’t seem to be a fixed name for it. In libraries like mediasoup, this concept is often called a pipe.

Usually, SFU server, does not support clustering or load balancing. Because an SFU server is just one of peers in WebRTC stack, so the idea of splitting it into multiple instances isn’t something that’s natively supported. Because of this, performance is inherently limited by the server’s specs, and ensuring fault tolerance by running multiple instances is also challenging.

How Relay Works

Typically, RTP packets received from client “a” by server “A” can only be viewed by clients connected to server “A” (client “c”). The relay mechanism allows these packets to be forwarded to clients connected to server “B”, effectively enabling cross-server streaming.

Current Implementation

For now, I’ve built a simple prototype that transfers RTP packets from server “A” to server “B” using UDP. However, this communication does not utilize the WebRTC stack. It’s just a direct transfer of RTP packets over UDP. Of course, I’ve implemented logic to ensure that the source and destination can be identified, but it’s not using DTLS, and the receiving side is just a basic UDP server. This means that RTP packets for various destinations are all coming in through the same UDP server. The performance implications of this approach are still unknown.

Issue: RTCP feedbacks

RTCP is a protocol where the receiving side sends feedback to the sending side, and in most WebRTC implementations, it flows from the receiver to the sender. Whether or not to handle it is up to the implementation, but it will be sent regardless. However, as mentioned earlier, the relay servers in the current setup are only forwarding RTP packets, so RTCP, which involves reverse-direction communication, is not being handled.

For server “A”, since client “a” is directly connected to it, RTCP packets can simply be forwarded there. However, for server “B”, the current architecture does not account for communication in the direction of server “B” -> server “A”, meaning there’s no way to send RTCP feedback back to the original sender. If I need to implement this, it would essentially require bidirectional communication. At that point, if I’m going to establish bidirectional communication over UDP anyway, I might as well switch to WebRTC, which would simplify the process.

Because of this, I might change this approach in the future.

Challenges and Future Improvements

I suspect that making this server-to-server relay WebRTC-based would result in a more stable implementation. However, there are several concerns.

The first is signaling — server-to-server communication requires its own signaling mechanism, separate from client-server signaling. This raises the question of whether signaling should be built into the library itself. I haven’t fully settled on an answer yet, but if I were to use something, gRPC seems like a viable option.

Another concern is port usage. When WebRTC communicates over UDP, it consumes a port, and typically, that port isn’t reused. This means that every time a server receives RTP packets from a client, it consumes a port. If another client connects to the same server, another port is consumed. Linux only supports up to 65,535 ports, and many lower-numbered ports are reserved for other purposes, making them unavailable for UDP. This means there’s a hard limit on the number of users that can be supported. Moreover, if server-to-server RTP relaying also consumes ports, the number of ports used can increase significantly. For example, if a server receives a single video stream and relays it to 10 other servers, it would use 1 port for receiving and 10 ports for relaying. On top of that, additional ports are required for clients receiving the stream. This becomes a serious issue.

Performance

I haven’t checked the performance in a production environment, but, currently, it works in my local machine properly, so the performance is not completely unusable.

The only way to check the performance is to prepare many clients and stream simultaneously. I plan to try this at some point. However, if you use this library and have any performance issues, I would appreciate it if you could report them to me. I will improve it.

Why I use Rust

First of all, recently, I like to write Rust. It has powerful memory management capabilities that extend to parallel processing. In the SFU, a lot of parallel processing is required, but at the same time, high-speed single-thread performance such as receiving and sending RTP packet is also required. I thought Rust would be a good fit for this requirement.

Conclusion

Developing an SFU library from scratch has been an interesting challenge. By leveraging Rust’s strong memory safety and concurrency features, I’ve been able to build a system that efficiently processes RTP packets while keeping SFU-related logic separate from signaling.

While the current implementation works well locally, significant improvements are needed:

- Enhanced relay mechanism
- Comprehensive performance testing
- E2E tests
- Recording feature

I welcome feedback and contributions from the community. If you’re interested in WebRTC SFU development in Rust, I’d love to hear your thoughts!

While some additional hiccups cropped up along the way (https://github.com/pixelfed/pixelfed/issues/5426), the issues appear to be fully addressed on pixelfed.social, allowing OAuth code authentication to work smoothly.

With this improvement, Pixelfed support has been added to Megalodon, enabling seamless integration with both Whalebird and Fedistar. Now, Pixelfed users can access their accounts and enjoy these apps’ streamlined user experiences.

What’s Missing?

While the authentication process is finally sorted, there are still some limitations in what Pixelfed can offer, primarily due to its current feature set.

No WebSocket Streaming

Pixelfed does not support WebSocket-based streaming, which means real-time features like notifications or live timeline updates are unavailable. This limitation isn’t specific to third-party apps — it’s absent even in Pixelfed’s web client.

While these features could be added in the future, for now, users will need to refresh manually for updates.

No Lists

Another significant limitation is the lack of support for lists, a feature commonly found in other Fediverse platforms. Without lists, apps cannot offer list-based functionalities, making it harder to organize your feed.

No Text-Only Posts

As a photo-sharing-focused platform, Pixelfed does not allow text-only posts without attachments. This required additional validation within the apps to ensure compliance with Pixelfed’s posting requirements.

The Bottom Line

Despite these limitations, the introduction of Pixelfed support in Whalebird and Fedistar marks a big step forward for users seeking a smoother way to interact with the platform. While there’s still room for growth — like real-time updates and list management — Pixelfed’s integration into these apps adds significant value, and it’s exciting to see how things will evolve from here.

Background and Considerations

The idea of rewriting Whalebird first emerged around April 2023. During a previous update, I replaced the Node.js store (which had been using nedb) with better-sqlite3 for security reasons and the robustness of SQL. However, this choice turned out to be less than ideal. better-sqlite3 relied on native extensions, causing issues with missing SQLite binaries during cross-builds.

Next on the list was Vue3. While I had partially migrated to Vue3 in 2022, the experience wasn’t particularly enjoyable. Although Vue2 lacked comprehensive type definitions and editor autocompletion, it excelled in ease of use. However, as the application grew, Vue3 became less convenient. Despite gaining better type support, Vue3 still left some areas without proper type coverage, leaving me with mixed feelings.

Choosing React and Next.js

In the latter half of 2023, I explored several alternatives for the rewrite. While Svelte was part of the experimentation, it had a grate editor autocmopletion. However, it is similar to Vue.js, and I didn’t want to use something like Vue again. Ultimately, I decided to transition to React. The choice of Next.js was pragmatic — its stability and suitability for Electron applications played a significant role.

Additionally, whether it’s Next.js, React.js, or Remix, I wanted to stick with traditional SPA architecture and client-side rendering. Svelte was excluded due to its limitations in this regard.

The Rewrite and Its Impact

Almost all the code underwent a rewrite, resulting in a significantly lighter application. Most of the logic now resides on the frontend, minimizing the need for IPC (inter-process communication). While this means background tasks are nearly impossible, the lightweight nature of the app renders them unnecessary.

For styling, I’ve adopted Tailwind CSS, which works well. However, I discovered that not all components libraries are Tailwind-compatible, limiting my choices.

Upcoming Implementations

Several features remain to be implemented:

1. Search: Automatic completion for usernames, hashtags, and emojis.
2. Proxy Configuration: Handling proxy settings.
3. Follow Requests: Managing follow requests.

In summary, Whalebird’s transition from Vue.js to React.js (specifically Next.js) has been an interesting journey. The decision-making process involved trade-offs, but overall, the app is now more streamlined and ready for further enhancements.

Fedistar is a multi-column Fediverse client app. Once, I introduced it.

I’m developing a new Fediverse client application for desktop

It supports Windows, MacOS, and Linux. You can install it from the official Web site.

Fedistar

Now, Fedistar is published only in AppStore, but I will try to publish it in

• Snapcraft
• Homebrew
• Microsoft Store
• Winget

Also, I would say that Fedistar is very light and fast.

Features

Basically, it has typical features as a multi-column client.

• Multiple accounts management
• Streaming update
• Desktop notifications
• Reblog/Favourite/Bookmark/Emoji reaction/Edit statuses
• Show status threads
• Display link preview
• Poll/Vote
• Auto-complete username, hashtags, and emoji in compose tab
• Show media: image, video, and audio

And there is a unique feature.

• See timelines without sign in

Planned Features

I created some issues in GitHub. For example,

• Search accounts and hashtags
• Change color theme
• Tag timeline
• Reblog and Favourite from another account
• Specify post language
• Jump to unread notifications when clicking the server

I will implement these features in near future. Especially, I’m considering how to implement “Reblog and Favourite from another account”. Once, I’ve had a request like that, and I know it is a little bit tricky.

Feature Requests and Bug Reports

Please create issues in GitHub,

GitHub - h3poteto/fedistar: Multi-column Mastodon and Pleroma client for desktop

Or please send it from the contact form.

Inqiury - Fedistar

I welcome your opinion. Feel free to send it. Or, you can reply to @h3poteto@pleroma.io .

I have developed a Mastodon client for Mac, Windows, and Linux

Whalebird is a single-column Fediverse client application. It can display only one timeline on the screen.

Recently, I bought a big monitor (it is very good for programming), and after that, I’m not satisfied with Whalebird. Because I want to see more information, statuses, and timelines on the screen. So, I’m creating a new multi-column Fediverse client app.

Fedistar

The new app name is “Fedistar”. Before creating the new app, I considered how about implementing multi-column on Whalebird. However,

1. I want to clean up the current code.
2. I don’t want to write Vue.js anymore.
3. In the first place, the architecture could be better for multi-column.

So, I’m creating a new client app.

Here is a screenshot.

And the repository is

GitHub - h3poteto/fedistar: Multi-column Mastodon and Pleroma client for desktop

This app has some characteristic features:

1. You can add servers without authorization. In this case, you can see only Public and Local timelines, and you can’t reply, reblog, and favourite. You can only see the timeline.
2. You can choose which account to post from.
3. It supports Mastodon and Pleroma, at the moment. I’m wondering about Misskey, Friendica, and Pixelfed.
4. And some other features typical of multi-column clients.

I’ve created issues that I want to implement before version 1.0.0. Except for these issues, I’m planning

• When you react to status, you can choose which account to do from…… Is it possible, I’m not sure.
• Read notifications count from markers.
• Jump to the notification when you receive a notification.
• Icon

Development

I used Electron and Vue.js in Whalebird, but now I’m using tauri and Next.js. So, probably it is smaller and faster than Whalebird. I’ve never measured that memory and CPU usage, so I can’t say for sure.

Then tauri executes the main process with Rust, so I created the Rust version of megalodon which is a client library for Mastodon, Pleroma, and Misskey for JavaScript. I spent a month working on this……

GitHub - h3poteto/megalodon-rs: Mastodon and Pleroma API client library for Rust

Of course, I also had the option to call all Fediverse API requests from the frontend. However, I didn’t choose it, because it is easier and performs better to execute WebSocket streaming in the main process. So, I’m using megalodon-rs in the main process and megalodon in the frontend.

Regarding the frontend, I’m using Next.js. There are two reasons for this

1. I don’t want to write Vue.js anymore.
2. React.js has a richer library and ecosystem.

For example, Virtual Scroll is important in SNS timelines, but it is also very important to maintain the scroll position simultaneously. Few libraries provide this in React.js, but there is no library in Vue.js.

Under development

This software is under development, so there is no stable version yet. I will implement breaking changes before 1.0.0, so if you want to develop this, please install it. That’s why it is not distributed in stores, for example, Mac App Store, and Snap Store. It will be stable when it reaches version 1.0.0, and at that time I will publish it in stores.

I’m not soliciting bug reports, because this software still has many unimplemented features. If you find an unexpected behavior, it is not a bug, it’s just unimplemented. Therefore, pull requests are welcome.

Questions and Answers

Not satisfied with Sengi or TheDesk?

No, not satisfied. I’d rather develop a client than just do Fediverse. In the first place, I started Fediverse because I couldn’t create a client on Twitter.

Are there any differences between them?

Who knows? It is not important for me, because the app is free and I’m not looking for sales. So there is no need to differentiate and spread this app.

What are you going to do with Whalebird?

Updates will be less frequent. However, I will continue to develop as long as you need single-column clients.

When is the stable version released?

I don’t know.

Android or iOS version?

No, I have no plan. In mobile, I think that multi-column is not suitable.

Welcome

However, what should we do when you want to create a Global Accelerator in front of the Load Balancer? I have developed an OSS to solve it.

GitHub - h3poteto/aws-global-accelerator-controller: A Kubernetes controller for Global Accelerators and Route53

How to use

This controller can manage AWS Global Accelerator and Route53 records from Service and Ingress resources. And it detects annotations from Service and Ingress to control AWS resources, so you only need to add a few annotations.

• When you add aws-global-accelerator-controller.h3poteto.dev/global-accelerator-managed: "yes"as an annotation, a Global Accelerator will be created and the related LoadBalancer will be added to an Endpoint Group.
• When you add aws-global-accelerator-controller.h3poteto.dev/route53-hostname: your.hostnameas an annotation, route53 records associated with the Global Accelerator will be created.

Use it with Service type Load Balancer

Please create a Service type: LoadBalancer, and specify the above annotations.

apiVersion: v1
kind: Service
metadata:
  annotations:
    aws-global-accelerator-controller.h3poteto.dev/global-accelerator-managed: "yes"
    aws-global-accelerator-controller.h3poteto.dev/route53-hostname: "foo.h3poteto-test.dev"
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
  name: h3poteto-test
  namespace: default
spec:
  externalTrafficPolicy: Local
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: 80
    - name: https
      port: 443
      protocol: TCP
      targetPort: 443
  selector:
    app: h3poteto
  sessionAffinity: None
  type: LoadBalancer

After you apply this resource,

• A Network Load Balancer will be created. You can confirm it in the Service.

status:
  loadBalancer:
  ingress:
    - hostname: your-lb-name.elb.ap-northeast-1.amazonaws.com

• A Global Accelerator will be created, and the Load Balancer will be added as an Endpoint Group
• foo.h3poteto-test.dev record will be created

Use it with AWS Load Balancer Controller

AWS Load Balancer Controller has a plan to support Global Accelerator.

[Feature Request] Global LoadBalancer support · Issue #1572 · kubernetes-sigs/aws-load-balancer-controller

But the controller I built is unrelated to this issue.

When you use Ingress, the way is very similar.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: h3poteto-test
  namespace: default
  annotations:
    aws-global-accelerator-controller.h3poteto.dev/global-accelerator-managed: "yes"
    aws-global-accelerator-controller.h3poteto.dev/route53-hostname: "foo.h3poteto-test.dev,bar.h3poteto-test.dev"
    alb.ingress.kubernetes.io/scheme: internet-facing
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: h3poteto-test
            port:
            number: 80

You can specify multiple hostnames in the route53-hostname annotation.

Use it with ingress-nginx

First, please add aws-global-accelerator-controller.h3poteto.dev/global-accelerator-managed annotation to the Service of ingress-nginx. If you are using helm, you can add it using the following command:

$ helm install ingress-nginx ingress-nginx/ingress-nginx \
--set controller.service.annotations."aws-global-accelerator-controller\.h3poteto.dev/global-accelerator-managed"="yes"

Next, please apply your ingress resource.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: h3poteto-test
  namespace: default
  annotations:
    kubernetes.io/ingress.class: nginx
    aws-global-accelerator-controller.h3poteto.dev/route53-hostname: "foo.h3poteto-test.dev,bar.h3poteto-test.dev"
spec:
  rules:
  - http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: h3poteto-test
            port:
              number: 80

How it works

This controller is monitoring Service and Ingress resources and checks annotations when it is changed. And it creates Global Accelerators if needed. However, this controller waits until the Load Balancer becomes active. After the Load Balancer becomes active, it will create a new Global Accelerator. If there is no related Load Balancer, it will not create any Global Accelerators even if you specify the annotation.

Furthermore, it creates Route53 records after Global Accelerator is created. Also at this time, if there is no Global Accelerator, it will not create any Route53 records even if you specify the annotation.

How to detect the created Accelerator

Of course, Kubernetes Service does not have a field to store created Global Accelerator name, so the controller can not save it to the Service resource.

The controller saves the Service or Ingress resource name in Global Accelerator’s tag. Based on the information, it is determined whether or not a Global Accelerator for that Service was created.

How to detect the created Route53 record

In route53, this controller adopted the same method as external-dns. That means it stores the Service or Ingress resource name in a TXT record.

Future work

I’ve created some issues like these.

• Binding existing Global Accelerator
  This is similar to the Target Group Binding of AWS Load Balancer Controller. I want to add a Load Balancer as an EndpointGroup to the existing Global Accelerator.
• Support endpoint weight
  If the above feature is implemented, I want to specify endpoint weight for each Service or Ingress.

If you have some requests, feel free to create issues or pull requests. I would be happy to review your PR.

Epilogue

I’m working at oVice as a part-time developer, and I developed this controller for oVice. Because oVice’s Kubernetes clusters are using ingress-nginx and we wanted to add Global Accelerator for our services.

However, oVice decided to stop using ingress-nginx and we will use ALB and TargetGroup Binding of AWS Load Balancer Controller. Our application needs to track client IP addresses, but Global Accelerator with NLB can not preserve client IP addresses. On the other hand, Global Accelerator with ALB can preserve it. So we decided to change the Load Balancer.

Generally, when using TargetGroup Binding, ALB and TargetGroup are managed by another method, for example, Terraform. In that case, Global Accelerator and Route53 records should also be managed by Terraform.

So, we create ALB, TargetGroup, Global Accelerator, and Route53 records with Terraform. As a result, unfortunately, we don’t need to use this controller in oVice……

That’s why this repository has become my hobby OSS. oVice will not support this, but I will continue to develop.

Thank you.

Manage AWS Global Accelerator from Kubernetes resources was originally published in oVice on Medium, where people are continuing the conversation by highlighting and responding to this story.

Release v1.23.0 · kubernetes/kops

For some time kOps has supported IRSA.

Using IAM Roles for ServiceAccounts on kOps

But before kOps 1.23, you need to install eks-pod-identity-webhook manually.

GitHub - aws/amazon-eks-pod-identity-webhook: Amazon EKS Pod Identity Webhook

In kOps 1.23, you can specify spec.podIdentityWebhook.enabled to true , and kOps installs eks-pod-identity-webhook automatically.

Pod Identity Webhook

When you specify spec.podIdentityWebhook , you need to enable cert-manager. For example:

spec:
  podIdentityWebhook:
    enabled: true
  certManager:
    enabled: true

After creating a new cluster, eks-pod-identity-webhook pods are deployed in kube-system .

$ kubectl get pods -n kube-system
NAME                                                                        READY   STATUS    RESTARTS        AGE
cert-manager-84955789dd-g2djl                                               1/1     Running   0               3m54s
cert-manager-cainjector-6475d566f7-jtx99                                    1/1     Running   0               3m54s
cert-manager-webhook-7b7b64cc86-t64dk                                       1/1     Running   0               3m54s

## Omission

pod-identity-webhook-565f794b7c-gffkd                                       1/1     Running   0               3m54s
pod-identity-webhook-565f794b7c-scrf8                                       1/1     Running   0               3m54s

In conclusion, these steps are needed

1. Create an S3 bucket (public readable)
2. Specify spec.serviceAccountIssuerDiscovery in your cluster spec
3. (Optional) Specify spec.iam.serviceAccountExternalPermissions
4. Specify spec.podIdentityWebhook
5. Create a cluster using kOps

spec:
  serviceAccountIssuerDiscovery:
    discoveryStore: s3://public-readable-s3-bucket-name
    enableAWSOIDCProvider: true
  iam:
    serviceAccountExternalPermissions:
      - name: my-sa
        namespace: my-ns
        aws:
          inlinePolicy: |-
            [
              {
                "Effect": "Allow",
                "Action": "ec2:Describe*",
                "Resource": "*"
              }
            ]
  podIdentityWebhook:
    enabled: true
  certManager:
    enabled: true

That’s it, IRSA is set up.

How to use IRSA

Create ServiceAccount

Create a Service Account that you specified in iam.serviceAccountExternalPermissions.

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::00000000:role/my-sa.my-ns.sa.cluster-name
  name: my-sa
  namespace: my-ns

You can find eks.amazonaws.com/role-arn using this command.

$ aws iam get-role --role-name my-sa.my-ns.sa.cluster-name
{
    "Role": {
        "Path": "/",
        "RoleName": "my-sa.my-ns.sa.cluster-name",
        "RoleId": "***********",
        "Arn": "arn:aws:iam::00000000:role/my-sa.my-ns.sa.cluster-name",
        "CreateDate": "2022-03-17T12:25:46+00:00",
        "AssumeRolePolicyDocument": {
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Effect": "Allow",
                    "Principal": {
                        "Federated": "arn:aws:iam::00000000:oidc-provider/public-readable-s3-bucket-name.s3.us-east-1.amazonaws.com"
                    },
                    "Action": "sts:AssumeRoleWithWebIdentity",
                    "Condition": {
                        "StringEquals": {
                            "public-readable-s3-bucket-name.s3.us-east-1.amazonaws.com:sub": "system:serviceaccount:my-ns:my-sa"
                        }
                    }
                }
            ]
        },
    }
}

Note: If you don’t specify spec.iam.serviceAccountExternalPermissions , you need to create an IAM Role that allows sts:AssumeRoleWithWebIdentity .

This is a terraform example for the IAM Role.

resource "aws_iam_role" "my-sa" {
  name = "my-sa.my-ns.sa"
  path = "/"

  inline_policy {
    name = "my_inline_policy"

    policy = jsonencode({
      Version = "2012-10-17"
      Statement = [
        {
          Action   = ["ec2:Describe*"]
          Effect   = "Allow"
          Resource = "*"
        },
      ]
    })
  }

  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::00000000:oidc-provider/public-readable-s3-bucket-name.s3.us-east-1.amazonaws.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "public-readable-s3-bucket-name.s3.us-east-1.amazonaws.com:sub": "system:serviceaccount:my-ns:my-sa"
        }
      }
    }
  ]
}
EOF
}

You can find Federated using this command.

$ aws iam list-open-id-connect-providers
{
    "OpenIDConnectProviderList": [
        {
            "Arn": "arn:aws:iam::00000000:oidc-provider/public-readable-s3-bucket-name.s3.us-east-1.amazonaws.com"
        }
    ]
}

Check the behavior

Create a job to confirm the behavior.

apiVersion: batch/v1
kind: Job
metadata:
  name: awscli
  namespace: my-ns
spec:
  template:
    spec:
      restartPolicy: Never 
      serviceAccountName: my-sa
      containers:
        - name: awscli
          image: amazon/aws-cli:latest
          args: ["ec2", "describe-instances", "--region", "ap-northeast-1"]
  backoffLimit: 0

Environment variables and Volumes are injected by eks-pod-identity-webhook.

spec:
  containers:
  - args:
    - ec2
    - describe-instances
    - --region
    - ap-northeast-1
    env:
    - name: AWS_ROLE_ARN
      value: arn:aws:iam::564677439943:role/my-sa.my-ns.sa.playground.k8s.h3poteto.dev
    - name: AWS_WEB_IDENTITY_TOKEN_FILE
      value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
    image: amazon/aws-cli:latest
    imagePullPolicy: Always
    name: awscli
    # Omission
  volumes:
  - name: aws-iam-token
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          audience: amazonaws.com
          expirationSeconds: 86400
          path: token

And the commandaws ec2 describe-instances is succeeded in the pod 🎉

$ kubectl logs -f awscli-xbksl -n my-ns
{
    "Reservations": [
        {
            "Groups": [],
            "Instances": [
                {
                    "AmiLaunchIndex": 0,
                    "ImageId": "ami-********",
                    "InstanceId": "i-0f4e3e20cf27d652c",
                    "InstanceType": "t3.medium",
                    "KeyName": "******",
                    "LaunchTime": "2022-03-11T15:25:05+00:00",
                    "Monitoring": {
                        "State": "disabled"
                    },
                    "Placement": {
                        "AvailabilityZone": "ap-northeast-1c",
                        "GroupName": "",
                        "Tenancy": "default"
                    },