the WordPress.com #Reader is now a client for #Bluesky, #Mastodon and your #ActivityPub enabled Blog.
...more to come :)
activitypub.blog/2026/05/22/y...
Your WordPress Site — From RSS...
検索
返信元:
While working on #Fedify, I noticed something about how #Misskey handles #ActivityPub object access. When a remote server requests a followers-only post or DM with a valid HTTP Signatures (draft-cavage) from an authorized actor, Misskey still returns 404 instead of the content. It seems Misskey only checks the visibility field (public/home) without verifying the signature at all.
#Mastodon takes a different approach—when #authorized_fetch is enabled, it validates the HTTP Signatures and returns the content if the requesting actor has permission. I think it would be beneficial if Misskey could adopt a similar mechanism, since it would better respect the access control semantics that ActivityPub intends. Has anyone else run into this, or are there specific reasons Misskey handles it this way?
#fedidev
Fedifyを開発していて気づいたことなんですが、MisskeyのActivityPubオブジェクトへのアクセス処理について少し疑問があります。リモートサーバーから、アクセス権限のあるアクターの有効なHTTP Signaturesを含むリクエストでフォロワー限定投稿やDMにアクセスしようとしても、Misskeyは内容を返さずに404を返すようです。どうやらMisskeyはHTTP Signaturesを検証せず、visibilityフィールド（publicとhome）だけを確認しているようです。
Mastodonの場合、authorized fetchを有効にすると、HTTP Signaturesを検証して、リクエストしているアクターに権限があれば内容を返します。MisskeyもMastodonのような仕組みを採用してくれたら、ActivityPubが意図しているアクセス制御のセマンティクスをより適切に尊重できるんじゃないかと思います。他の方も同じようなことに気づかれたことはありますか？それとも、Misskeyがこのような処理をしている特別な理由があるのでしょうか？
#Fedify #Misskey #ActivityPub #Mastodon #authorized_fetch #fedidev
❤ 1
While working on #Fedify, I noticed something about how #Misskey handles #ActivityPub object access. When a remote server requests a followers-only post or DM with a valid HTTP Signatures (draft-cavage) from an authorized actor, Misskey still returns 404 instead of the content. It seems Misskey only checks the visibility field (public/home) without verifying the signature at all.
#Mastodon takes a different approach—when #authorized_fetch is enabled, it validates the HTTP Signatures and returns the content if the requesting actor has permission. I think it would be beneficial if Misskey could adopt a similar mechanism, since it would better respect the access control semantics that ActivityPub intends. Has anyone else run into this, or are there specific reasons Misskey handles it this way?
#fedidev
#Mastodon では、数字だけの場合はハッシュタグにしないという仕様かな？
それならば、#WordPress のプラグイン #ActivityPub に実装するのは意外に簡単。末尾が ; の場合にハッシュタグにしないようにすれば、カラーコードの方を除外するのも簡単。
I've just published version 2.85 of #snac, the simple, minimalistic #ActivityPub instance server written in C. It includes the following changes:
Quoted posts are now shown.
Added metadata to remote users in the people page (contributed by dandelions).
Fixed memory leak (contributed by dandelions).
Fixed user matching (contributed by rakoo).
Rendering visibility conditionally, with lesser reach if needed (contributed by byte).
Added a button next to a follow notification to follow back.
Fixed typo in man page (contributed by spky).
Updated Czech and German translations (contributed by pmjv and zen).
https://comam.es/what-is-snac
If you find #snac useful, please consider buying grunfink a coffee or contributing via LiberaPay.
#snacAnnounces #FrugalFediverse
みんなで別の一つの場所に引っ越しするんじゃなくて、それぞれが #ActivityPub :activitypub: に対応した場所に行けばいいじゃない？ :tony_normal: :fediverse:
「Twitterからの移住先なんてあるワケねぇぇぇんだよぉぉぉぉぉぉォォォ～～～～～～～～～～～～～！！」長すぎるポストなのに共感集まる - Togetter
https://togetter.com/li/2634207
#mixi2 ちゃんと継続改善頑張ってて好感持ってる。
#ActivityPub :activitypub: 対応して #Fediverse :fediverse: 化してくれないかな〜いつか… :tony_smirking:
いずれにしても、応援してます！ :mastodon_mascot:
https://mixi.social/@nibushibu/posts/5f5c7ead-542b-4d69-a98b-dad541fa0006
Concept for discussion: Replacing HTTP Signatures with Bearer Tokens for ActivityPub Federation
Curious what other people think about this idea. What if federation security was re-worked to use target-assigned bearer tokens to authenticate GET/POST requests? This would remove the need for complicated signing schemes and reduce system load under heavy traffic bursts (as no cryptography is required).
A basic implementation could look like this:
1. When instance A (
2. Instance B makes a POST request back to a dedicated verification endpoint on instance A (for discussion, we'll say it's
3. Instance A checks the verification token (and verify that it matches the target domain name) and return a successful value. The verification code must be invalidated after this call!
4. Instance B, after verifying instance A's request, returns a securely-generated federation key back to instance A. This federation key is a bearer token used to authenticate all requests from instance A to instance B. This key must be unique to instance A!
5. Instance A completes the original request with the
6. Instance B receives the request, detects the federation key, and checks it against the list of registered instances.
7. If the key does not exist or A has been defederated, then a [
8. If the key is expired or revoked, then [
9. If the key is approved, then a [
Advantages versus HTTP Signatures:
- No cryptography requirements.
- Simple logic, no edge cases around HTTP query parameters or header order.
- Equally effective for all request types.
- Keys can be easily revoked or rotated.
- Supports authorized fetch and defederation use cases "by default".
Disadvantages versus HTTP Signatures: - Breaks the actor model - instances are required as a first-class concept. (but really, the actor model is basically dead already. you can't even federate reliably without a WebFinger server, at minimum.) - Requires multi-request "handshake" before communication. (but this is already required in practice, since a signature can't be validated without first requesting the signing actor.) - Out-of-band protocol - communication can't happen over ActivityPub / ActivityStreams because this is a prerequisite to authenticate any request. (but again, we already require WebFinger and some software requires NodeInfo for full support.) So, what are your thoughts? Good idea? Bad idea? Did I miss something? Please let me know, I welcome replies here! #ActivityPub #AP #Federation
A basic implementation could look like this:
1. When instance A (
a.example.com) first attempts to federate with instance B (b.example.com), a POST request is made to a dedicated registration endpoint. (for discussion, we'll say it's https://b.example.com/activity-pub/register-instance). This request includes fields necessary for verification, including the source domain name, target domain name, and a securely-generated verification token. Other metadata could be included to allow instance B to selectively allow/prohibit federation based on other criteria, but this is optional.2. Instance B makes a POST request back to a dedicated verification endpoint on instance A (for discussion, we'll say it's
https://a.example.com/activity-pub/verify-registration). This request must include the target domain name and verification token provided in step 2.3. Instance A checks the verification token (and verify that it matches the target domain name) and return a successful value. The verification code must be invalidated after this call!
4. Instance B, after verifying instance A's request, returns a securely-generated federation key back to instance A. This federation key is a bearer token used to authenticate all requests from instance A to instance B. This key must be unique to instance A!
5. Instance A completes the original request with the
Authorization header set to Bearer {federation_key}.6. Instance B receives the request, detects the federation key, and checks it against the list of registered instances.
7. If the key does not exist or A has been defederated, then a [
403 Forbidden error](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/401) is returned.8. If the key is expired or revoked, then [
401 Unauthorized error](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/401) is returned. Upon receiving a 401 error, instance A should start over from step 1 to re-authenticate and complete the request with a new token. This process should not be repeated for recursive failures!9. If the key is approved, then a [
200 OK response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/200) or [202 Accepted response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/202) is returned, and A can consider the request as successful.Advantages versus HTTP Signatures:
- No cryptography requirements.
- Simple logic, no edge cases around HTTP query parameters or header order.
- Equally effective for all request types.
- Keys can be easily revoked or rotated.
- Supports authorized fetch and defederation use cases "by default".
Disadvantages versus HTTP Signatures: - Breaks the actor model - instances are required as a first-class concept. (but really, the actor model is basically dead already. you can't even federate reliably without a WebFinger server, at minimum.) - Requires multi-request "handshake" before communication. (but this is already required in practice, since a signature can't be validated without first requesting the signing actor.) - Out-of-band protocol - communication can't happen over ActivityPub / ActivityStreams because this is a prerequisite to authenticate any request. (but again, we already require WebFinger and some software requires NodeInfo for full support.) So, what are your thoughts? Good idea? Bad idea? Did I miss something? Please let me know, I welcome replies here! #ActivityPub #AP #Federation
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @[email protected] project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
#opensource #mentoring #ActivityPub #fedidev
こんなのもあったのか
新時代の分散型SNS「Concrnt(コンカレント)」を始めよう！｜akiRAM https://note.com/akiram_vr/n/nfe5419e4ba2a
#Fediverse #ActivityPub
As someone who has developed several #ActivityPub software implementations (Fedify, Hollo, BotKit, and Hackers' Pub), I believe one of the most frustrating features to implement in the #fediverse is #custom_emoji.
The challenges are numerous:
First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.
Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.
Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like
:party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.
What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.
#fedidev
おー、Mastodonにおける引用機能の開発状況についてのエントリが来てる。引用対象の制限や引用された投稿の切り離しを検討しているあたり、やはりBlueskyを参考にしているところがあるな。
そして、やるからにはActivityPubの仕様として作っていくつもりでいると。
/ Bringing Quote Posts to Mastodon - Mastodon Blog
https://blog.joinmastodon.org/2025/02/bringing-quote-posts-to-mastodon/
#mastodon #fedibird #activitypub
Hello, I'm an open source software engineer in my late 30s living in #Seoul, #Korea, and an avid advocate of #FLOSS and the #fediverse.
I'm the creator of @[email protected], an #ActivityPub server framework in #TypeScript, @[email protected], an ActivityPub-enabled microblogging software for single users, and @[email protected], a simple ActivityPub bot framework.
I'm also very interested in East Asian languages (so-called #CJK) and #Unicode. Feel free to talk to me in #English, #Korean (#한국어), or #Japanese (#日本語), or even in Literary Chinese (#文言文, #漢文)!
#introduction
とても分かりやすかった。ActivityPub連携できるんだね！後で登録してみよ〜！
新時代の分散型SNS「Concrnt(コンカレント)」を始めよう！｜akiRAM
https://note.com/akiram_vr/n/nfe5419e4ba2a
#Concrnt #activitypub #fediverse #fedibird
:botkit: Introducing #BotKit: A #TypeScript framework for creating truly standalone #ActivityPub bots!
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust @[email protected] foundation.
https://botkit.fedify.dev/