洪 民憙(ホン・ミンヒ)
@[email protected] · Reply to 洪 民憙(ホン・ミンヒ)'s post
印刷所に注文した『自分だけのフェディバースのマイクロブログを作ろう!』の紙の本、到着した‼️
@[email protected] · 7 following · 373 followers
Fedify is a TypeScript library for building federated server apps powered by ActivityPub and other standards, so-called fediverse. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
Website | GitHub | JSR | npm |
---|---|---|---|
@[email protected] · Reply to 洪 民憙(ホン・ミンヒ)'s post
印刷所に注文した『自分だけのフェディバースのマイクロブログを作ろう!』の紙の本、到着した‼️
@[email protected] · Reply to Fedify: an ActivityPub server framework's post
@fedify good to mention: there is also a Matrix space for those who are like "why discord?!"
#Fedify now has an #AMQP driver! This means you can use #RabbitMQ as Fedify's message queue. To use it, first install the @fedify/amqp package, then set it up like below:
import { createFederation } from "@fedify/fedify";
import { AmqpMessageQueue } from "@fedify/amqp";
import { connect } from "amqplib";
const federation = createFederation({
queue: new AmqpMessageQueue(await connect("amqp://localhost")),
// ... other configurations
});
Oh, and we've also added results from AmqpMessageQueue
to our benchmarks.
#Fedify takes 20 minutes for GitHub Actions to finish. What do you think?
Option | Voters |
---|---|
That's too slow. Optimize it now. | 0 (0%) |
Not fast, but tolerable. | 0 (0%) |
Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
If you're curious, take a look at the #Fedify website! There's comprehensive docs, a demo, a tutorial, example code, and more:
If you're on the fence about which driver to choose for #Fedify's message queue, here's a benchmark that just came out. In addition to no queue, we compare 5 drivers, for a total of 11 setups:
InProcessMessageQueue
DenoKvMessageQueue
RedisMessageQueue
PostgresMessageQueue
AmqpMessageQueue
InProcessMessageQueue
× 4DenoKvMessageQueue
× 4RedisMessageQueue
× 4PostgresMessageQueue
× 4AmqpMessageQueue
× 4Curious to see the results? Check out the GitHub repository!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
@thisismissem Here's the benchmark, and while it contains some questionable results, the overall conclusion is as following:
• Response times are much faster with queues than without.
• Overall throughput is better without queues.
• However, some queue setups can achieve throughput close to that of no queue.
This benchmark assumes communication within a single node, so the effect of queues may be greater in real-world networks.
#Fedify now has an #AMQP driver! This means you can use #RabbitMQ as Fedify's message queue. To use it, first install the @fedify/amqp package, then set it up like below:
import { createFederation } from "@fedify/fedify";
import { AmqpMessageQueue } from "@fedify/amqp";
import { connect } from "amqplib";
const federation = createFederation({
queue: new AmqpMessageQueue(await connect("amqp://localhost")),
// ... other configurations
});
Oh, and we've also added results from AmqpMessageQueue
to our benchmarks.
The #Fedify repository has reached 500 stars! Thank you everyone!
10月26日(土)に開催されるOSC 2024 Tokyo/FallにFedify/Hollo合同で出展します!可愛いFedifyのロゴのシールと『自分だけのフェディバースのマイクロブログを作ろう!』日本語版の紙の本を持って行く予定です。よろしくお願いします。
自作ActivityPubサーバーに興味が有る方は、ActivityPubサーバーフレームワークであるFedifyを一度使ってみてください。ちなみに、公式日本語チュートリアルである『自分だけのフェディバースのマイクロブログを作ろう!』がZennにも掲載されています。
What's your biggest wish for Fedify?
Option | Voters |
---|---|
RabbitMQ driver | 5 (21%) |
Kafka driver | 3 (13%) |
AWS SQS driver | 2 (8%) |
Nuxt integration | 3 (13%) |
AdonisJS integration | 2 (8%) |
Fastify integration | 4 (17%) |
NestJS integration | 3 (13%) |
Koa integration | 2 (8%) |
If you're considering creating your own implementation of #ActivityPub, consider #Fedify.
Implementing ActivityPub from scratch requires more than you might think. WebFinger, HTTP Signatures, Linked Data Signatures, Object Integrity Proofs, NodeInfo, queues for sending and receiving activities, followers collection synchronization, remote object lookups, interoperability with Mastodon, Akkoma, Misskey, Threads, and more…
Just use Fedify and feel free to create your own ActivityPub implementation!
Did you know that? The #Fedify CLI has a command called fedify lookup
, which can easily look up ActivityStreams objects on servers with authorized fetch (a.k.a. secure mode) enabled by turning on the -a
/--authorized-fetch
flag.
@[email protected] · Reply to Steve Bate's post
If you're on the fence about which driver to choose for #Fedify's message queue, here's a benchmark that just came out. In addition to no queue, we compare 5 drivers, for a total of 11 setups:
InProcessMessageQueue
DenoKvMessageQueue
RedisMessageQueue
PostgresMessageQueue
AmqpMessageQueue
InProcessMessageQueue
× 4DenoKvMessageQueue
× 4RedisMessageQueue
× 4PostgresMessageQueue
× 4AmqpMessageQueue
× 4Curious to see the results? Check out the GitHub repository!
@[email protected] · Reply to 洪 民憙 (Hong Minhee)'s post
@thisismissem Here's the benchmark, and while it contains some questionable results, the overall conclusion is as following:
• Response times are much faster with queues than without.
• Overall throughput is better without queues.
• However, some queue setups can achieve throughput close to that of no queue.
This benchmark assumes communication within a single node, so the effect of queues may be greater in real-world networks.
If you're considering creating your own implementation of #ActivityPub, consider #Fedify.
Implementing ActivityPub from scratch requires more than you might think. WebFinger, HTTP Signatures, Linked Data Signatures, Object Integrity Proofs, NodeInfo, queues for sending and receiving activities, followers collection synchronization, remote object lookups, interoperability with Mastodon, Akkoma, Misskey, Threads, and more…
Just use Fedify and feel free to create your own ActivityPub implementation!
独自のActivityPubの実装を作りたい方は、Fedifyを検討してみてください。
ActivityPubをゼロから実装するには、想像以上に多くの物を作る必要が有ります。WebFinger、HTTP Signatures、Linked Data Signatures、Object Integrity Proofs、NodeInfo、アクティビティの送受信のキュー、フォロワーコレクションのシンクロ、リモートオブジェクトの照会、MastodonやMisskey等との相互運用性の為の雑多な処理まで…Fedifyを使えば簡単に自分だけのActivityPubの実装を作る事が出来ます!
New: Last Week in #Fediverse - ep 86
This week's news:
- Threads degrades their #activitypub integration, delaying posts by 15 minutes before they appear in the rest of the fediverse
- Website League is a new ActivityPub-based Island network, outside of the rest of the fediverse
- Ghost discusses their beta plans and pricing.
Adding vocabularies for FEP-9091 to #Fedify.
Did you know that? The #Fedify CLI has a command called fedify lookup
, which can easily look up ActivityStreams objects on servers with authorized fetch (a.k.a. secure mode) enabled by turning on the -a
/--authorized-fetch
flag.
Fedifyを使うのを躊躇う理由が有れば?
Option | Voters |
---|---|
機能不足 | 0 (0%) |
抽象化レベルが低い | 0 (0%) |
TypeScriptに慣れていない、または好みではない | 0 (0%) |
日本語の資料の少なさ | 0 (0%) |
GhostとHollo以外の実例がな | 0 (0%) |
その他(リプライで教えてください) | 0 (0%) |
Are you excited about the #fediverse but find implementing #ActivityPub daunting? Meet #Fedify, a #TypeScript framework that simplifies building federated server apps. Whether you're creating the next Mastodon, Pixelfed, or something entirely new, Fedify has you covered.
Fedify abstracts away the complexities of ActivityPub, letting you focus on your app's unique features. It's designed to work seamlessly with popular web frameworks like Hono, Express, and Fresh.
Check out our step-by-step tutorial to create a microblog: https://fedify.dev/tutorial/microblog
Explore the discussions, contribute, or just star us on GitHub: https://github.com/dahlia/fedify
Join the Fedify community! Questions? Ideas? Find us on Matrix: #fedify:matrix.org.
Let's build a more diverse and interoperable fediverse together with Fedify!
I'm adding the #EmojiReact (FEP-c0e0) class to #Fedify… It will be coming in Fedify 1.1.0.
[[Fedify]] looks cool:
> Fedify is a TypeScript library for building federated server apps powered by ActivityPub and other standards, so-called fediverse.
h/t @band
@[email protected] · Reply to naDne :blobcatmelt2: :debian: 's post
@FiFachik @rf Для тех, кто хочет потестить федерирование для своего бложика с поддержкой #ActivityPub, могу только посоветовать #Fedify. Там есть встроенная команда для подключения к сервису на выбор, который может дать временный домен для тестирования.
ActivityPub 서버 프레임워크인 Fedify가 드디어 첫 스테이블 버전인 1.0.0을 릴리스했습니다!
ActivityPubのサーバーフレームワークであるFedifyがついに最初の正規バージョンである1.0.0をリリースしました!
https://zenn.dev/hongminhee/articles/c913bbf8030412
QT: https://hollo.social/@fedify/019229e7-4fdc-7a46-a0ec-d383566a49cc [参照]
Fedify, an ActivityPub framework, has finally released its first stable version, 1.0.0! Here are key changes:
From this version, the term handle across Fedify will only be used to refer to fediverse handles (e.g., @[email protected]
). 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.
For more details, please refer to the related documentation.
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.
For more details, please refer to the related documentation.
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.)
For more details, please refer to the related documentation.
Delete(Application)
on fedify inbox
terminationFrom 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.
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.
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!
If you're a hands-on learner and want to learn how to build for ActivityPub, I urge you to try out @fedify.
The documentation alone is a great way to understand the underlying mechanics, and you'll be prototyping ideas in no time. I've been using it for the last few months and can't recommend it enough.
They just launched their first stable release: https://fedify.dev/
s/o to @hongminhee for this fantastic resource.
Fedify, an ActivityPub framework, has finally released its first stable version, 1.0.0! Here are key changes:
From this version, the term handle across Fedify will only be used to refer to fediverse handles (e.g., @[email protected]
). 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.
For more details, please refer to the related documentation.
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.
For more details, please refer to the related documentation.
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.)
For more details, please refer to the related documentation.
Delete(Application)
on fedify inbox
terminationFrom 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.
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.
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!