While Nostr and AT Protocol (used by Bluesky social) may appear similar on the surface, there are subtle differences between them.

Nostr can be seen as a self-contained protocol where relays are capable of implementing their own content moderation policy and store only the content that users have transmitted to the relay.

It is the clients that implement their own User Interface and algorithm.

Conversely, the Authenticated Transfer Protocol (AT Protocol) is intended to serve as the underlying protocol for multiple social networks (applications).

Using AT Protocol, each application can implement its own user interface and content moderation, but the data is held in the users' own data repository.

Additionally, users will be able to select the algorithm used to surface content. These competing algos will be available in a marketplace.

Similarities:

- Both are protocols

- Both are open source

- Both utilise public key cryptography for identity

- Both are used to enable a social network experience

Differences:

Data storage -

Nostr users transmit data (notes) to relays who store these notes.

AT Protocol users have a Data Repository, which applications can request access to read.

This Data Repository stores content, such as:

- Identity

- Profile

- Social graph

- Content (posts, comments, likes, media blobs, etc.)

This data is saved locally on your laptop / phone, depending on available storage, and is .

Key Rotation -

Nostr uses a simple pub / priv key pair for authentication. It does not natively support key rotation.

If the private key is compromised, the user cannot easily revoke access to the compromised key.

AT Protocol natively supports a root private key (Recovery Key), which is used to authorise a signing key.

If the signing key is compromised, the user can issue a new signing key using their Recovery key.

Moderation -

Nostr relays and/or clients are able to implement their own moderation policy.

Relays and/or clients may(?) be responsible for compliance and takedown requests.

Applications built on top of the AT Protocol are able to implement their own moderation policy and are responsible for takedown requests, however this data would still exist in the users Personal Data Repository.

Account Portability -

Competing social networks (think Instagram, Facebook, and Twitter) can use the AT Protocol to request access to this data, which is controlled by the user.

This makes account portability possible, meaning it would be possible to login to competing social media platforms, with their own interfaces, features and moderation policies, but still retain your contacts and supported content.

So who is the winner?

Based on my (extremely limited) understanding of both, AT Protocol is more complex but is superior from a user data, key management and algorithm selection perspective.

The Personal Data Repository structure allows users to store their data and authorise or revoke access to this data by applications.

Additionally, users are able to rotate keys in the event that their signing key is compromised and select the algorithm used to surface content.

*** would appreciate if anyone can correct / clarify any points I may have misunderstood or expand on any areas where warranted

Reply to this note

Please Login to reply.

Discussion

based on my basic understanding, it has a few advantages

#[2]

is this a fair comparison?

(would love an invite btw)

#[2]

here is a basic comparison:

#[2]

As Black Swan asks, anyone have more to add, consider on this topic?

#[0]

Thanks for this writeup! Still trying to learn up on AT protocol and DID. Although I think on “who’s the winner?” part, the answer is protocol-based social media platforms! Kinda mind blowing that we are talking abt 2 platforms and multiple social media clients now when just 2 mths ago we were fully controlled by centralised comms platforms !

Absolutely!

And you are 100% correct, it is the decentralised protocols and the users who really win. 💜

Thanks a lot 🙏🏻

No probs, check out Zion also. Similar to Bluesky (using a DID for identity) but has built in lightning ⚡️ support!

Can’t zap on Damus yet but sent you some sats via your lightning link ⚡️🧡

Legend, thank you!

Sounds promising

Yep, looks like the space is finally heating up.

Check out Zion also if you get a chance. uses DIDs like Bluesky but with native lightning ⚡️ integration like Nostr!

Great explanation of the differences between #Nostr and BlueSky by #[1] ⚡️⚡️

#[2]

Yes #[3]

#[0]

これ読んで少しだけ違いを理解できました。

DeepL訳

--

NostrとATプロトコル(Bluesky socialで使用)は、一見似ているように見えますが、微妙に違うところがあるのです。

Nostrは、リレーが独自のコンテンツモデレーションポリシーを実装することができ、ユーザーがリレーに送信したコンテンツのみを保存する自己完結型のプロトコルと見なすことができます。

独自のユーザーインターフェースとアルゴリズムを実装するのはクライアントである。

逆に、ATプロトコル(Authenticated Transfer Protocol)は、複数のソーシャルネットワーク(アプリケーション)の基礎プロトコルとして機能することを意図しています。

AT Protocolを使うことで、各アプリケーションは独自のユーザーインターフェースやコンテンツモデレーションを実装できるが、データはユーザー自身のデータリポジトリに保持される。

さらに、ユーザーはコンテンツのサーフェスに使用するアルゴリズムを選択することができるようになります。これらの競合するアルゴリズムは、マーケットプレイスで入手できるようになる。

類似点

- どちらもプロトコルである

- オープンソースであること

- アイデンティティに公開鍵暗号を使用

- どちらもソーシャルネットワークを実現するために使用される

相違点

データの保存

Nostrユーザーは、データ(ノート)をリレーに送信し、リレーはそのノートを保存します。

ATプロトコルのユーザーはデータリポジトリを持ち、アプリケーションはそのデータリポジトリの閲覧を要求することができる。

このデータリポジトリには、以下のようなコンテンツが格納されます。

- アイデンティティ

- プロフィール

- ソーシャルグラフ

- コンテンツ(投稿、コメント、「いいね!」、メディアブロブなど)

このデータは、利用可能なストレージに応じて、あなたのノートパソコンや携帯電話にローカルに保存され、.

鍵のローテーション

Nostrは、認証に単純なpub / privキーペアを使用します。これは、ネイティブでキーローテーションをサポートしていません。

秘密鍵が漏洩した場合、ユーザーは漏洩した鍵へのアクセスを簡単に取り消すことができません。

AT Protocolは、署名鍵を認証するために使用されるルート秘密鍵(Recovery Key)をネイティブにサポートしています。

署名鍵が漏洩した場合、ユーザーは自分のリカバリーキーを使って新しい署名鍵を発行することができます。

モデレーション

Nostrのリレーおよび/またはクライアントは、独自のモデレーションポリシーを実装することができます。

リレーおよび/またはクライアントは、コンプライアンスとテイクダウン要求に責任を持つことができます(?

ATプロトコル上に構築されたアプリケーションは、独自のモデレーションポリシーを実装することができ、テイクダウン要求に責任を持ちますが、このデータは依然としてユーザーの個人データリポジトリに存在することになります。

アカウントのポータビリティ

競合するソーシャルネットワーク(Instagram、Facebook、Twitterなど)は、ATプロトコルを使用して、ユーザーが管理するこのデータへのアクセスを要求できます。

つまり、独自のインターフェース、機能、モデレーションポリシーを持つ競合するソーシャルメディアプラットフォームにログインしても、連絡先やサポートされているコンテンツは保持されることになります。

では、誰が勝者なのでしょうか?

私の(極めて限られた)理解では、AT Protocolはより複雑ですが、ユーザーデータ、鍵管理、アルゴリズム選択の観点からは優れています。

個人データリポジトリ構造により、ユーザーは自分のデータを保存し、アプリケーションによるこのデータへのアクセスを承認または取り消すことができます。

さらに、署名鍵が漏洩した場合に備えて鍵をローテーションさせたり、コンテンツ表示に使用するアルゴリズムを選択したりすることも可能です。

*** 私が誤解していると思われる点を訂正/明確化したり、必要な部分を拡大したりできる方がいらっしゃいましたら、感謝いたします。

DeepLで翻訳しました (https://www.deepl.com/app/?utm_source=ios&utm_medium=app&utm_campaign=share-translation

bluesky與nostr的區別,主要是數據儲存方式跟帳號子密鑰使用的區別

#[0]

nip26和at实现效果差不多,所以就是at = nostr + s0str?

Nostr协议更简洁。

私钥管理和数据管理交给丰富可选的第三方应用或自建realy,协议层并无必要做出任何倾向性选择。

未来Nostr上会出现个人傻瓜relay套餐

由于这里的公钥用户群体和已积累用户行为数据是共享的,融入不同闪电网络技术的,形形色色的客户端功能会层出不穷。

也会出现有关信息流管理的,可选付费订阅的算法推荐或应用插件市场。

#[1]

Wow, that's really interesting, thank you.

User control over their data (also deletion and privacy settings) is to me super important and indeed, doesn't seem that amazing on Nostr so far. Clients should at least guide users to help them save their data.

Key rotation as well.

So, those features you tell from AT Protocol are compelling.

One of the biggest brake for adoption is that not many people want to spend time creating a whole new network on a new place and this is understandable. While migrating towards decentralized Social Networks, the ability of potential clients being able to fetch data from various protocols would be the real game changer.

Exciting to see what will develop but to me, the prospect of having too many different of those protocols that couldn't communicate doesn't give me a good expectation for mass adoption.

Lack of key rotation is the thing I dislike most about Nostr. Its seems like there should be 3 keys: a generated private key which is kept offline and generate new signing and public keys, a signing key which is used in clients to sign messages, and a public key.

Relying on browser extensions for key management seems like a poor choice

From what I understand from the official documents, PDS (Personal Data Servers) is actually very similar to relay, they are most likely to be normal servers, not personal devices. Posts are still sync in different PDS.

What's difference is:

1. on top of TPS/relay, there's a index crawler to handle events that's not in your closer social. (Section Achieving Scale),

2. User need to give PDS signing key to do anything with their events, which can be overriden by the user's Recover key. (Section Account Portability)

3. "Federation was chosen to ensure the network is convenient to use and reliably available." This is the biggest doubt I have after reading it, who choose which PDS to be included ?

But there is also DID documents store in personal devices, which you can broadcast to the other PDSs when the ones you are using is down. Check Account portability section. This is not in nostor protocol, but I think at least is working on it. (And I believe is a good idea the keep the protocol minimum and neat.)

https://atproto.com/guides/overview

#Nostr #AT #ATProtocol #SocialNetwork #Bluesky #OpenSource

Yep, you’re correct!

It was this sentence that I misinterpreted:

‘A backup of the user’s data is persistently synced to their client as a backup (contingent on the disk space available).’

The local copy is just that, a backup, allowing the user to migrate to a different PDS.

Thank you for clarifying!