What is Hackers' Pub?

Hackers' Pub is a place for software engineers to share their knowledge and experience with each other. It's also an ActivityPub-enabled social network, so you can follow your favorite hackers in the fediverse and get their latest posts in your feed.

1
0
0
0

SMTP 설정 건드리고 여기저기 포탈이메일 서비스에서 잘 수신되는지 테스트를 하는데

지메일이나 네이버메일은 별 문제 없지만,
카카오,다음 이메일은 여전히 1~4분 지연되서 도착하는구나.

지연되는 것도 문제지만, 먼저 보낸 이메일이 나중에 보낸 이메일보다 후에 도착하는 경우도 있어서
인증 이메일로 쓰기에는 매우 부적합한듯.

6,7년전에 테스트했을 때도 그랬는데, 그동안 나아진게 없구나.

0

SMTP 설정 건드리고 여기저기 포탈이메일 서비스에서 잘 수신되는지 테스트를 하는데

지메일이나 네이버메일은 별 문제 없지만,
카카오,다음 이메일은 여전히 1~4분 지연되서 도착하는구나.

지연되는 것도 문제지만, 먼저 보낸 이메일이 나중에 보낸 이메일보다 후에 도착하는 경우도 있어서
인증 이메일로 쓰기에는 매우 부적합한듯.

6,7년전에 테스트했을 때도 그랬는데, 그동안 나아진게 없구나.

0

Bot同士が会話してる! :panda_kirakira:

とか見かけたら、普通の人は微笑ましく思うじゃないですか。

運営者の目線でみると、こいつら無限に会話して暴走する恐れがある! ヤベエ! 危険だ!! って思うんですよ……

0
0

1. 羞辱式言語除了出氣,並不可能說服誰。當然人有出氣的需要,但不必在別人的地方用這種方式出自己的氣。

2. 把意見不同的人群「非人化」,貶之為畜、為蛆,是歷史上幾乎所有集權政體對少數群體遂行集體暴力的標準手段。我們要警惕,不要變得和他們一樣。

3. 語言是有力量的,你使用什麼樣的語言,反映出你是什麼樣的人。所以,我盡量不使用方便的、標籤式的劣質語言。

4. 這裡是我的個人社群空間,不認同也不勉強,不必強留。

(圖:DALL.E)

0

지속되는 이명은 거의 줄어들었지만 간헐적으로 들리는 이명은 여전함
사실 오래전부터(아마 초등학생 때부터) 가끔씩 이명이 들렸어서 특별한 증상이 아닌 걸 수도

0
0
0
0

how is this not
EVERY REVIEW on this product says "Amazon Vine Customer Review of Free Product"

anytime i see high % of vine i know something i very wrong with the product for you to have to lie with vine reviews to sell it. i avoid high % vine review products. was gonna get this tell i noticed 100% of reviews are vine.

funny BS of vine reviews i notice on are not even about same prodcut or Ai

About Vine: amazon.com/vine/about

Product: amazon.com/product-reviews/B0D

0
1

Okay so let's presume I wanted to do some strength training with the goal of eventually obtaining the body of an Amazonian warrior, but that I'm currently extremely fat and exceptionally out of shape and asthmatic and can't afford a gym membership. How the fuck do I even start

0
0
0
0
0

1. 羞辱式言語除了出氣,並不可能說服誰。當然人有出氣的需要,但不必在別人的地方用這種方式出自己的氣。

2. 把意見不同的人群「非人化」,貶之為畜、為蛆,是歷史上幾乎所有集權政體對少數群體遂行集體暴力的標準手段。我們要警惕,不要變得和他們一樣。

3. 語言是有力量的,你使用什麼樣的語言,反映出你是什麼樣的人。所以,我盡量不使用方便的、標籤式的劣質語言。

4. 這裡是我的個人社群空間,不認同也不勉強,不必強留。

(圖:DALL.E)

0
0
1
0

We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in , complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.

This implementation includes both signature generation and verification, meaning is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other implementations. Once these tests confirm compatibility, we'll proceed with the merge.

As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the . Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.

Currently, we support RSA-PKCS-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.

We look forward to contributing to a more standardized and secure fediverse!

HTTP Message Signatures

This API is available since Fedify 1.6.0.

RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.

Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.

NOTE

Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.Double-knocking HTTP Signatures

This API is available since Fedify 1.6.0.

As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.

To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
1
0
1

Mastodonの新規登録については、管理画面でこんな設定ができるようになっててね、

・誰でも登録可
・登録には承認が必要
・誰にも許可しない

の選択と、

☑ 申請事由の入力を必須にする

ってチェックがある。

承認制は2019年から存在する機能だよ。

『誰でも登録可』になってると、以下の注意が表示されるようになっている。

> モデレーションチームがスパムや悪意のある登録を迅速に処理できる自信がない限り、サインアップを承認制にすることをお勧めします。

あと、招待制というのは、実際には『誰にも許可しない』にしておいて、招待URLからの登録だけを受け付ける状態のこと。

招待URLは、誰も発行できないか、管理者だけ発行できるようにするか、利用者にも許可するか、選択するようになっている。(fedibird.comの場合は利用者は誰でも発行できる設定になっているよ)

『誰でも登録可』でモデレーション権限のある誰かが1週間ログインしていない状態が続いている場合、放置されてて危険ということで、自動的に『登録には承認が必要』に変更する機能もついている。(この機能は無効に設定することもできる)

『サーバー設定』の『アカウント作成』タブ新規登録が可能な人

・誰でも登録可
・登録には承認が必要
・誰にも許可しない

申請事由の入力を必須にする
0
1
0
0
0

Finanzsenator , der öffentlich dazu aufgerufen hat, unser nicht zu unterstützen, ist weder von den , die er dazu verbreitet hat, abgerückt, noch möchte er den Aufruf zurücknehmen - aber er möchte ihn auch nicht als rechtswidrige Einflussnahme verstanden wissen:

Es handle sich um ein Statement von einem "privaten Account", angeblich "außerhalb des amtlichen Kontextes" - und damit sei es in Ordnung, weil ja auch für den Senator "Meinungsfreiheit" gelte - ungeachtet der öffentlichen Wirkung seiner Worte.

Hamburg hat also einen , der keine für seine Worte übernimmt.

0
0

We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in , complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.

This implementation includes both signature generation and verification, meaning is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other implementations. Once these tests confirm compatibility, we'll proceed with the merge.

As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the . Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.

Currently, we support RSA-PKCS-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.

We look forward to contributing to a more standardized and secure fediverse!

HTTP Message Signatures

This API is available since Fedify 1.6.0.

RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.

Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.

NOTE

Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.Double-knocking HTTP Signatures

This API is available since Fedify 1.6.0.

As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.

To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
1
0
1

We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in , complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.

This implementation includes both signature generation and verification, meaning is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other implementations. Once these tests confirm compatibility, we'll proceed with the merge.

As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the . Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.

Currently, we support RSA-PKCS-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.

We look forward to contributing to a more standardized and secure fediverse!

HTTP Message Signatures

This API is available since Fedify 1.6.0.

RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.

Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.

NOTE

Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.Double-knocking HTTP Signatures

This API is available since Fedify 1.6.0.

As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.

To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
1
0
1

We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in , complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.

This implementation includes both signature generation and verification, meaning is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other implementations. Once these tests confirm compatibility, we'll proceed with the merge.

As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the . Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.

Currently, we support RSA-PKCS-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.

We look forward to contributing to a more standardized and secure fediverse!

HTTP Message Signatures

This API is available since Fedify 1.6.0.

RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.

Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.

NOTE

Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.Double-knocking HTTP Signatures

This API is available since Fedify 1.6.0.

As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.

To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.
1
0
1
1
0
0
0
0
0
0
1
0
1
1
1
0
0
0
0
0