标签: 协议

  • IPFS 的新宠:Helia,让 JavaScript 开发者拥抱去中心化

    IPFS(星际文件系统)作为一种去中心化的文件存储和分发协议,正逐渐成为 Web3 世界的基石。而 Helia 作为 IPFS 在 JavaScript 和浏览器端的现代化实现,为开发者提供了更便捷、高效的工具,让他们能够轻松地将 IPFS 集成到自己的应用中。

    Helia 的优势

    Helia 拥有以下几个关键优势:

    • 模块化: Helia 采用模块化设计,开发者可以根据自己的需求选择不同的模块组合,例如选择使用 HTTP 网关或 libp2p 进行网络连接。
    • 现代化: Helia 基于 TypeScript 开发,提供类型安全和代码提示等现代化开发体验。
    • 易用性: Helia 提供了一系列易于使用的 API,让开发者能够快速上手,将 IPFS 集成到自己的应用中。

    Helia 的应用场景

    Helia 可以应用于多种场景,例如:

    • 去中心化存储: 使用 Helia 存储网站、应用程序、数据等,避免依赖中心化的服务器。
    • 内容分发: 使用 Helia 分发内容,提高内容的可用性和安全性。
    • 去中心化应用开发: 使用 Helia 开发去中心化的应用,例如去中心化的社交网络、去中心化的存储服务等。

    Helia 的使用示例

    以下是一些使用 Helia 的示例:

    • 存储字符串:
    import { createHelia } from 'helia';
    import { strings } from '@helia/strings';
    
    const helia = await createHelia();
    const s = strings(helia);
    
    const myImmutableAddress = await s.add('hello world');
    
    console.log(await s.get(myImmutableAddress));
    // hello world
    • 存储 JSON 对象:
    import { createHelia } from 'helia';
    import { json } from '@helia/json';
    
    const helia = await createHelia();
    const j = json(helia);
    
    const myImmutableAddress = await j.add({ hello: 'world' });
    
    console.log(await j.get(myImmutableAddress));
    // { hello: 'world' }
    • 存储 DAG-JSON 对象:
    import { createHelia } from 'helia';
    import { dagJson } from '@helia/dag-json';
    
    const helia = await createHelia();
    const d = dagJson(helia);
    
    const object1 = { hello: 'world' };
    const myImmutableAddress1 = await d.add(object1);
    
    const object2 = { link: myImmutableAddress1 };
    const myImmutableAddress2 = await d.add(object2);
    
    const retrievedObject = await d.get(myImmutableAddress2);
    console.log(retrievedObject);
    // { link: CID(baguqeerasor...) }
    
    console.log(await d.get(retrievedObject.link));
    // { hello: 'world' }

    Helia 的未来

    Helia 正在不断发展,未来将会有更多功能和改进,例如:

    • 更强大的 API: 提供更丰富的 API,支持更多功能,例如文件系统操作、数据加密等。
    • 更好的性能: 优化性能,提高数据存储和检索速度。
    • 更广泛的应用: 支持更多应用场景,例如 Web3 应用、物联网应用等。

    总结

    Helia 是 IPFS 在 JavaScript 和浏览器端的现代化实现,为开发者提供了更便捷、高效的工具,让他们能够轻松地将 IPFS 集成到自己的应用中。随着 IPFS 的不断发展,Helia 将会扮演越来越重要的角色,推动 Web3 世界的构建。

    参考文献

  • 如何增强互联网的记忆力?

    IPFS(InterPlanetary File System)是一个点对点的媒体传输协议,旨在建立一个持久的、分布式的文件系统。它通过内容寻址的方式来定位和获取文件,使得文件在网络中具有高可用性的特性[2]。而dreamlink.cloud是一个基于IPFS的静态网站,提供了一系列在去中心化P2P网络上运行的工具[1]

    以下是对IPFS和dreamlink.cloud的介绍:

    IPFS的特点:

    • 去中心化:IPFS没有特权节点,所有节点都是平等的,任何用户都可以存储和分享文件内容[2]
    • 内容寻址:IPFS使用内容的哈希值作为文件的唯一标识,通过请求哈希值来获取文件内容,而不是通过地址寻址[2]
    • 高可用性:IPFS中的文件可以被存储在成千上万的节点中,即使某个节点宕机或下线,其他节点仍然可以获取到文件内容[2]
    • 安全性:IPFS使用哈希值来校验文件内容的完整性,如果文件在传输过程中被篡改,哈希值将与请求的哈希值不一致,从而保证了数据的安全性[2]

    dreamlink.cloud的特点:

    • 无需安装IPFS节点:dreamlink.cloud提供了一个在Web浏览器中运行的IPFS节点,用户无需自行安装节点即可使用IPFS功能[1]
    • 无限制的文件分享:用户可以上传文件和文件夹,没有账户、大小或带宽限制,实现自己的文件提供者角色[1]
    • 分布式搜索:通过ipfs-search.com进行文件和文件夹的搜索[1]
    • 文本粘贴板:用户可以创建和分享任何文本格式的内容[1]
    • 加密P2P聊天室:用户可以创建加密的P2P聊天室,与信任的人进行自由通信[1]

    IPFS和dreamlink.cloud的优势:

    • 高可用性和抗审查:IPFS的去中心化特性使得文件具有高可用性和抗审查的能力,而dreamlink.cloud作为基于IPFS的静态网站,进一步增强了这些特性[2]
    • 无需中心化服务器:与传统的互联网不同,IPFS和dreamlink.cloud不依赖于中心化的服务器托管商,任何人都可以注册一个节点,成为一个高效的文件提供者[2]

    IPFS是一个点对点的媒体传输协议,通过内容寻址的方式实现高可用性的分布式文件系统。而dreamlink.cloud则是一个基于IPFS的静态网站,提供了无需安装IPFS节点的文件分享、搜索、文本粘贴板和加密P2P聊天室等功能。


    Learn more:

    1. GitHub – opendreamnet/dreamlink.cloud: Static website with tools running entirely on IPFS.
    2. IPFS 介绍 | Verne in GitHub
    3. What Is the Interplanetary File System (IPFS) and How Do You Use It?
  • ActivityPub是一种开放的、基于分布式社交网络的协议

    Reblog via admin

    ActivityPub是一种开放的、基于分布式社交网络的协议,用于创建、更新和删除内容,并实现服务器之间的通信和内容传递。它为客户端到服务器和服务器到服务器提供了API接口,使得用户可以方便地在不同的社交网络平台之间进行交流和互动。

    ActivityPub的目标是构建一个去中心化的社交网络,让任何人都可以在网络上运行自己的节点,并与其他服务器上的用户进行关注、点赞、评论等互动。这种去中心化的架构使得用户可以更好地掌控自己的数据和隐私,并且不受单一平台的限制。

    ActivityPub使用ActivityStreams作为其词汇,它包含了表示社交网络中各种活动和内容的常用术语。ActivityStreams的词汇已经包含了大部分我们在社交网络中需要使用的词汇,但即使它没有覆盖到我们所需的所有情况,我们仍然可以通过扩展JSON-LD来自定义新的词汇。

    JSON-LD是一种用于表示语义数据的JSON扩展格式,它可以将数据组织成图形结构,并提供了一种机制来连接不同的数据源。对于了解JSON-LD的人来说,可以采取更加高级的链接数据方法;而对于不熟悉JSON-LD的人来说,JSON-LD文档和ActivityStreams可以被理解为普通的JSON格式。通过使用JSON-LD,我们可以更好地描述和表示社交网络中的各种活动和内容。

    在ActivityPub中,用户通过其在服务器上的帐户来表示为”actors”,每个帐户对应一个独立的”actor”。每个”actor”都有自己的收件箱(inbox)和发件箱(outbox),用于接收和发送消息。用户可以在发件箱中发布消息,其他用户可以通过收件箱接收到这些消息。服务器之间也可以相互传递消息和内容,以实现跨服务器的互联互通。

    举个例子,假设我们有两个用户Alyssa和Ben,他们分别在不同的服务器上拥有自己的帐户。当Alyssa想给Ben发送一条消息时,她会将消息发布到自己的发件箱中。然后,Alyssa的服务器会查找Ben的收件箱地址,并将消息发送到Ben的收件箱中。Ben可以通过检查自己的收件箱来读取Alyssa发送的消息。

    此外,ActivityPub还支持用户之间的关注、点赞、评论等互动。用户可以关注其他用户的帐户,以便在自己的收件箱中接收他们的消息。用户还可以对其他用户的帖子进行点赞或评论,这些互动也会通过服务器之间的通信进行传递。

    ActivityPub协议是世界广泛支持的社交网络标准,在Fediverse中得到了广泛应用。该标准由Evan Prodromou(StatusNet的创始人)等人共同编写,并于2018年1月被W3C发布为推荐标准。

    ActivityPub的独特之处在于它允许用户在不同的服务器上创建帐户,并与其他服务器上的用户进行互动。这种联邦架构使得用户可以选择自己喜欢的服务器,并与其他用户跨服务器进行关注、点赞、评论等互动。

    目前,许多社交网络平台已经实现了ActivityPub协议,包括Mastodon、PeerTube、Pixelfed等。这些平台都允许用户在自己的服务器上创建帐户,并与其他平台上的用户进行互动。用户可以通过关注其他用户的帐户,接收他们的消息和更新。他们还可以在自己的发件箱中发布消息,使其可供其他用户阅读和互动。

    此外,ActivityPub还支持用户之间的私信功能。用户可以通过私信功能与其他用户进行一对一的私密对话,这些对话只有双方能够看到。

    Mastodon是基于ActivityPub协议构建的一个开源微博平台,类似于Twitter。用户可以在Mastodon上创建自己的帐户,并与其他用户进行关注、点赞、评论等互动。Mastodon的一个独特之处在于它由许多独立的服务器组成,这些服务器之间通过ActivityPub协议进行通信,用户可以选择加入任何一个服务器。

    PeerTube是基于ActivityPub协议构建的一个开源视频分享平台,类似于YouTube。用户可以在PeerTube上上传和分享视频,并与其他用户进行互动。PeerTube的联邦架构允许用户自主选择他们信任的服务器,并在不同的服务器之间共享视频内容。

    Pixelfed是基于ActivityPub协议构建的一个开源图片分享平台,类似于Instagram。用户可以在Pixelfed上上传和分享图片,并与其他用户进行互动。Pixelfed的联邦架构使得用户可以选择他们喜欢的服务器,并与其他服务器上的用户进行互动。

    随着ActivityPub协议的不断发展和完善,越来越多的社交网络平台将采用这一标准。这将促进不同平台之间的互操作性和联邦互联,使用户能够更加自由地选择他们喜欢的平台,并与不同平台上的用户进行交流和互动。

    未来,我们可以期待更多创新和发展,例如更加智能化的内容推荐算法、更加灵活的隐私设置以及更加丰富的互动功能。ActivityPub将继续推动社交网络的去中心化和用户自主性的发展,为用户提供更加丰富、安全和自由的社交网络体验。

    参考文献:

    https://www.zhichai.net/activitypub%ef%bc%9a%e6%9e%84%e5%bb%ba%e5%88%86%e5%b8%83%e5%bc%8f%e7%a4%be%e4%ba%a4%e7%bd%91%e7%bb%9c%e7%9a%84%e5%bc%80%e6%94%be%e5%8d%8f%e8%ae%ae/

  • 100开头的IP地址:是公网还是内网?

    你是否留意过自家路由器的WAN口IP地址?最近,越来越多的用户发现自己的IP地址是以“100”开头。这是否意味着我们使用的都是内网IP呢?

    答案并非如此简单。许多人误以为所有以“100”开头的IP地址都是内网IP,但实际上,我们熟悉的内网IP地址仍然是以下三组:

    • 10.0.0.0/8
    • 172.16.0.0/12
    • 192.168.0.0/16

    那么,这些“100”开头的IP地址究竟是什么来头?

    “100”开头的IP地址:共享地址的秘密

    准确地说,这些IP地址属于 100.64.0.0 – 100.127.255.255 这个范围,根据 RFC 6598 的定义,它们并非私有地址,而是保留的共享地址,专门供网络服务提供商用于 NAT(网络地址转换)。

    简单来说,这些地址就像运营商内部的“VIP通道”,专门用于连接用户和真正的互联网。当你使用“100”开头的IP地址上网时,你的数据实际上需要经过运营商的NAT设备进行一次“中转”,才能最终到达目标服务器。

    共享地址带来的影响:速度与安全

    那么,使用这种共享地址上网会带来哪些影响呢?

    首先,最直观的影响就是网速。由于数据需要经过额外的NAT转换,因此访问速度相比直接使用公网IP会慢一些,尤其是在进行下载、游戏等对网络速度要求较高的活动时,这种差异会更加明显。

    当然,这种速度差异一般情况下并不明显,毕竟运营商的NAT设备性能强大,转换速度非常快。

    其次,使用共享地址还会影响到网络安全。由于你的设备没有直接暴露在公网上,因此黑客直接攻击你的设备会更加困难,相当于多了一层防护。

    共享地址的未来:IPv6时代即将到来

    运营商之所以采用这种共享地址的方式,主要原因还是 IPv4 地址资源的枯竭。为了在有限的IP地址资源下尽可能多地接入用户,NAT技术成为了目前最有效的解决方案。

    然而,随着 IPv6 协议的普及,这种共享地址的方式也将成为历史。在 IPv6 时代,每个设备都将拥有独立的IP地址,无需再进行NAT转换,网络速度和安全性都将得到极大提升。

    总结

    总而言之,“100”开头的IP地址并非传统意义上的内网IP,而是运营商为了缓解IPv4地址短缺而采取的临时措施。虽然它会对网络速度和访问方式造成一定影响,但总体而言还是利大于弊。相信在不久的将来,随着IPv6的普及,我们将彻底告别共享地址,迎来更加快速、安全的网络时代!

    参考文献:

    • RFC 6598 – IANA-Reserved Private Address Space
    • RFC 1918 – Address Allocation for Private Internets
  • SSE (Server-Sent Events) 概念和工作原理

    一、什么是 SSE?

    Server-Sent Events (SSE) 是一种服务器推送技术,允许服务器单向地将数据推送给客户端。与传统的客户端请求-服务器响应模式不同,SSE 允许服务器在任何时候主动向客户端发送数据,而无需客户端明确请求。

    二、SSE 的工作原理

    1. 建立连接: 客户端使用 EventSource API 建立到服务器的持久 HTTP 连接。
    2. 订阅事件流: 服务器端会生成一个事件流,并将数据以文本流的形式发送给客户端。
    3. 接收和处理数据: 客户端监听 message 事件,并在接收到数据时进行处理。
    4. 保持连接: 连接会一直保持,直到客户端或服务器断开连接。

    三、SSE 的特点

    • 单向推送: 数据传输方向是从服务器到客户端,客户端不能向服务器发送数据。
    • 基于 HTTP 协议: SSE 使用 HTTP 协议进行通信,无需额外的协议支持。
    • 轻量级: SSE 相比 WebSocket 更轻量级,更易于实现和维护。
    • 实时性: SSE 可以实现实时数据推送,但相较于 WebSocket 会有一定的延迟。

    四、SSE 的应用场景

    • 实时数据更新: 例如股票报价、新闻推送、社交媒体通知等。
    • 进度条显示: 例如文件上传、下载进度等。
    • 聊天应用: 例如简单的聊天室、客服系统等。

    五、SSE 与 WebSocket 的比较

    特性SSEWebSocket
    数据传输方向单向双向
    协议HTTPWebSocket
    复杂度
    实时性较低
    应用场景单向数据推送双向实时通信

    六、总结

    SSE 是一种简单高效的服务器推送技术,适用于单向实时数据推送的场景。它易于实现和维护,并且可以与现有 HTTP 基础设施良好兼容。

  • UDP打洞穿透NAT:突破网络限制的利器

    在现代网络通信中,我们常常遇到一个问题:由于网络中存在防火墙和NAT设备,使得处于不同网络环境下的计算机难以直接进行通信。为了解决这个问题,人们提出了各种技术和协议,其中UDP打洞穿透NAT成为了一种有效的解决方案。本文将深入探讨UDP打洞穿透NAT的原理和实现方法。

    NAT和NAT穿透

    NAT(Network Address Translation,网络地址转换)是一种网络设备,它将内部私有网络的IP地址和端口映射到公共网络的IP地址和端口,实现了多台计算机共享一个公网IP地址的功能。然而,NAT的存在也带来了一些问题,比如内网中的计算机无法直接被外网访问,导致了通信的限制。

    为了解决NAT带来的通信限制,人们提出了NAT穿透(NAT Traversal)的概念。NAT穿透是一种技术,通过各种手段和协议,使得处于不同网络环境下的计算机能够直接进行通信,而不需要经过中间服务器的转发。其中,UDP打洞就是一种常用的NAT穿透技术。

    UDP打洞的原理

    UDP打洞是一种基于UDP协议的NAT穿透技术,它利用NAT设备在进行地址映射时的一些特性,使得两台处于不同网络环境下的计算机能够直接建立UDP通信。

    在UDP打洞过程中,首先要确定自己的NAT类型。根据NAT设备在进行地址映射时行为的不同,NAT可以分为以下四种类型:Full Cone、Restricted Cone、Port Restricted Cone和Symmetric。判断自己的NAT类型可以使用一些工具或库,如PyStun。

    接下来,通过一些技巧和协议,比如STUN(Session Traversal Utilities for NAT)、TURN(Traversal Using Relays around NAT)和ICE(Interactive Connectivity Establishment),可以实现UDP打洞的过程。简单来说,UDP打洞的过程包括以下几个步骤:

    1. 客户端A向位于公网上的STUN服务器发送Binding Request消息,获取经过NAT转换后的公网地址和端口。
    2. 客户端A将获得的公网地址和端口发送给客户端B。
    3. 客户端B将自己的公网地址和端口发送给客户端A。
    4. 客户端A和客户端B尝试通过各自的NAT设备向对方发送UDP数据包。
    5. 如果两台设备的NAT设备允许数据包通过,那么它们就可以直接建立UDP通信。

    UDP打洞的实现

    为了更好地理解UDP打洞的实现过程,我们可以借助一些开源库,如ice4j。ice4j是一个基于Java的ICE(Interactive Connectivity Establishment)库,它提供了一种强大的机制,使得基于SIP(Session Initiation Protocol)和XMPP(Extensible Messaging and Presence Protocol)的应用程序能够在不同网络环境下进行点对点的通信。

    ice4j库的使用示例可以参考文献[1]中的代码。在实际应用中,我们可以根据具体的需求和网络环境进行相应的配置和调整,以实现UDP打洞的功能。

    UDP打洞的应用举例

    UDP打洞在网络通信中有着广泛应用。以下是一些常见的应用场景:

    1. 实时音视频通信:UDP打洞可以使得两台设备在不同网络环境下直接建立音视频通信,实现实时的语音和视频传输。
    2. P2P文件传输:UDP打洞可以使得两台设备在不同网络环境下直接进行文件传输,而不需要通过中间服务器的转发。
    3. 多人游戏联机:UDP打洞可以使得多台设备在不同网络环境下直接进行游戏联机,提供更好的游戏体验和互动性。
    4. IoT设备通信:UDP打洞可以使得不同的物联网设备在不同网络环境下直接进行通信,实现智能家居、智能城市等领域的互联互通。

    需要注意的是,UDP打洞虽然是一种有效的NAT穿透技术,但并不是万能的解决方案。在实际应用中,仍然需要考虑网络环境、安全性、稳定性等因素,并根据具体的需求选择合适的技术和协议。

    结语

    通过UDP打洞穿透NAT,我们可以突破网络限制,使得处于不同网络环境下的计算机能够直接进行通信。UDP打洞的实现依赖于一些技巧和协议,如STUN、TURN和ICE。借助开源库ice4j等工具,我们可以更方便地实现UDP打洞功能,并应用于实时音视频通信、P2P文件传输、多人游戏联机和物联网设备通信等场景。

    参考文献:
    [1] 试验UDP打洞穿透NAT_ice4j-CSDN博客, https://blog.csdn.net/liwf616/article/details/45507457

  • 解密 ActivityPub:社交网络去中心化的未来 (一)

    导语: 在互联网巨头掌控社交网络的时代,一个去中心化的未来正在悄然来临。ActivityPub 协议,作为构建去中心化社交网络的基石,正引领着这场变革。本文将深入浅出地介绍 ActivityPub 协议的基本原理,带您领略其运作机制,并探讨其如何赋能社交网络的未来。

    一、什么是 ActivityPub?

    ActivityPub 就像社交网络世界的通用语言,它定义了一套规则和规范,使得不同的社交平台能够相互理解和交流。想象一下,您在微博上发布了一条消息,您的朋友在微信上也能看到,这就是 ActivityPub 想要实现的目标。

    二、ActivityPub 的核心概念

    为了更好地理解 ActivityPub 的运作机制,我们需要先了解以下几个核心概念:

    • 参与者 (Actor): 在 ActivityPub 中,参与者可以是任何实体,例如用户、群组、网站等。每个参与者都有一个唯一的标识符 (Actor ID),类似于我们在社交平台上的用户名。
    • 收件箱 (Inbox): 每个参与者都有一个收件箱,用于接收来自其他参与者的信息,例如关注请求、消息通知等。
    • 发件箱 (Outbox): 与收件箱相对应,发件箱用于存储参与者发送的信息,例如发布的消息、关注请求等。
    • 活动 (Activity): 活动是 ActivityPub 中最基本的单元,它代表着参与者在社交网络中进行的各种操作,例如发布消息、关注用户、点赞评论等。

    三、如何构建社交关系?

    让我们以用户 Alice 和 Bob 为例,看看 ActivityPub 如何构建社交关系:

    1. Alice 关注 Bob: 当 Alice 点击“关注”按钮时,Alice 的社交平台会向 Bob 的收件箱发送一个“关注”活动。
    2. Bob 接受关注: Bob 的社交平台收到“关注”活动后,会向 Alice 的收件箱发送一个“接受”活动,表示接受 Alice 的关注请求。
    3. 社交关系建立: 至此,Alice 和 Bob 之间的社交关系就建立起来了。

    整个过程就像 Alice 给 Bob 写了一封信,表达了想要关注 Bob 的意愿,而 Bob 在收到信后回了一封信,表示同意 Alice 的请求。image.png

    四、ActivityPub 如何传递消息?

    ActivityPub 使用“活动”来传递各种类型的消息,例如公开消息、私信等。

    • 公开消息: 当用户发布一条公开消息时,社交平台会将这条消息打包成一个“发布”活动,并将该活动发送到所有关注该用户的收件箱中。
    • 私信: 私信的处理方式与公开消息类似,只是接收者的范围仅限于指定的私信对象。

    五、ActivityPub 的优势

    • 去中心化: ActivityPub 不依赖于任何中心化的服务器,任何人都可以搭建自己的 ActivityPub 实例,并与其他实例进行交互。
    • 开放标准: ActivityPub 是一个开放的标准,任何人都可以免费使用和实现。
    • 互操作性: ActivityPub 致力于实现不同社交平台之间的互联互通,打破平台壁垒。

    六、ActivityPub 的未来

    ActivityPub 正在构建一个更加开放、自由、去中心化的社交网络未来。随着越来越多的社交平台采用 ActivityPub 协议,我们将迎来一个全新的社交网络时代。

    参考文献:

    • Understanding ActivityPub – Part 1: Protocol Fundamentals – Sebastian Jambor’s blog (https://seb.jambor.dev/posts/understanding-activitypub/)
  • 去中心化社交协议:Nostr、ActivityPub、Farcaster 和 Lens Protocol 的比较

    本文将对四种主流的去中心化社交协议:Nostr、ActivityPub、Farcaster 和 Lens Protocol 进行比较分析,探讨它们的核心理念、主要功能、优缺点以及目标用户群体。

    评估去中心化社交协议的关键因素:

    • 账户创建和通信:用户如何在不依赖中心化服务器的情况下创建账户并进行互动?
    • 数据存储和社交图谱:用户数据(包括社交关系和内容)存储在哪里,如何访问?
    • 内容审核:协议如何解决垃圾邮件和有害内容等问题,同时维护言论自由原则?
    • 激励机制:如何激励服务提供商维护网络并确保其长期可持续性?

    1. Nostr:

    • 核心理念:Nostr 构建在去中心化的中继网络之上,优先考虑抗审查性和用户对数据的控制权。
    • 主要功能:
      • 用户创建公私钥对以进行身份验证。
      • 消息广播到连接的中继,并传递给连接到相同中继的用户。
      • 中继没有义务存储数据,但有些提供付费存储选项。
      • 内容审核由各个中继自行决定。
    • 优点:高度抗审查、设计简洁、方便使用比特币闪电网络支付。
    • 缺点:数据持久性可能是一个问题,由于缺乏集中审核,垃圾邮件和有害内容的风险增加。
    • 目标用户:比特币爱好者、隐私倡导者、寻求抗审查的用户。

    2. ActivityPub:

    • 核心理念:一种联合社交协议,类似于电子邮件,可实现互操作的社交网络。
    • 主要功能:
      • 用户在特定的实例(服务器)上创建帐户。
      • 实例之间相互通信以传递消息和共享数据。
      • 用户可以导出数据并迁移到其他实例。
      • 内容审核由各个实例自行处理。
    • 优点:用户体验熟悉,成熟的应用程序(如 Mastodon),允许具有不同审核政策的多元化社区。
    • 缺点:依赖实例管理员,实例关闭或审查的风险,缺乏针对实例运营商的明确激励机制。
    • 目标用户:寻求中心化社交媒体平台替代方案的用户,具有特定兴趣或价值观的社区。

    3. Farcaster:

    • 核心理念:旨在创建一个具有强大的数据存储层和用户友好应用程序的去中心化社交网络。
    • 主要功能:
      • 利用以太坊进行用户注册和身份验证。
      • 采用中心网络进行实时数据同步。
      • 计划引入订阅模式以创收。
      • 内容审核方法仍在开发中。
    • 优点:高度重视数据的持久性和可用性,通过订阅实现可持续资金的潜力。
    • 缺点:架构复杂,如果中心数量有限,可能会出现中心化问题。
    • 目标用户:寻求 Twitter 的去中心化替代方案的用户,注重数据所有权和可靠性。

    4. Lens Protocol:

    • 核心理念:利用区块链技术赋予用户对其社交数据的所有权和控制权。
    • 主要功能:
      • 建立在 Polygon 区块链之上,使用户能够以 NFT 的形式拥有他们的社交图谱和内容。
      • 允许创建具有不同功能和盈利模式的去中心化社交应用程序。
      • 强调应用程序之间的可组合性和互操作性。
      • 内容审核可以在应用程序级别实施。
    • 优点:真正拥有社交数据,创新的社交应用程序和盈利策略的潜力。
    • 缺点:与区块链技术相关的可扩展性挑战,潜在的高昂 Gas 费用。
    • 目标用户:精通加密的用户,寻求将其内容货币化的创作者,构建去中心化社交应用程序的开发人员。

    结论:

    选择哪种去中心化社交协议取决于个人需求和优先级。Nostr 提供简单性和抗审查性,ActivityPub 提供熟悉的联合模型,Farcaster 专注于数据持久性和用户体验,Lens Protocol 则通过基于区块链的所有权赋予用户权力。随着该领域的不断发展,这些协议可能会继续创新,并吸引寻求中心化社交媒体平台替代方案的不同社区。

  • Analysis of Decentralized Social Protocols: Nostr, ActivityPub, Farcaster, and Lens Protocol

    This article provides a comparative analysis of four prominent decentralized social protocols: Nostr, ActivityPub, Farcaster, and Lens Protocol. It delves into their design philosophies, underlying mechanisms, target audiences, and potential competitive advantages.

    Key Considerations for Evaluating Decentralized Social Protocols:

    • Account Creation and Communication: How do users establish identities and interact within the decentralized framework? This aspect examines the mechanisms for account registration, content posting, and private messaging without relying on centralized servers.
    • Data Storage and Social Graph: Where is user data, including social connections and content, stored? This is crucial for understanding data ownership, portability, and censorship resistance.
    • Content Moderation: How does the protocol address content moderation challenges, such as spam and harmful content, while upholding free speech principles?
    • Incentive Mechanisms: What incentives are in place to encourage participation from service providers and users, ensuring the protocol’s sustainability and growth?

    1. Nostr:

    • Focus: Censorship resistance and simplicity.
    • Mechanism:
      • Relies on a decentralized network of relays for message propagation.
      • Users connect to multiple relays, and messages are delivered to those shared between users.
      • Public-key cryptography ensures message authenticity and optional end-to-end encryption for private messages.
    • Data Storage: Distributed across connected relays, with optional data export and self-custody.
    • Content Moderation: Relay-specific, with most relays adopting a minimal moderation approach.
    • Incentives:
      • Low operational costs for basic relays.
      • Potential for premium services like extended data storage and content moderation as paid subscriptions.
    • Ecosystem:
      • Growing rapidly, fueled by the popularity of the Damus app.
      • Attracting a significant user base of Bitcoin enthusiasts.
      • Still in early stages, with many applications in the prototype phase.

    2. ActivityPub:

    • Focus: Decentralized alternative to traditional social media platforms.
    • Mechanism:
      • Employs a federated network of instances (servers).
      • Users register on specific instances, which communicate with each other to deliver messages.
    • Data Storage: Stored on the user’s chosen instance, with the option for export and migration.
    • Content Moderation: Instance-specific, allowing for diverse moderation policies across the network.
    • Incentives:
      • Primarily driven by community contributions and volunteer efforts.
      • Sustainability concerns due to the lack of robust monetization models for instance operators.
    • Ecosystem:
      • Mature ecosystem with established applications like Mastodon.
      • Attracts users seeking refuge from centralized censorship and control.

    3. Farcaster:

    • Focus: Building a decentralized social network with a user-friendly experience.
    • Mechanism:
      • Three-layer architecture: Ethereum blockchain for user registration, a network of hubs for data synchronization, and client applications.
      • Hubs maintain a real-time synchronized copy of the network’s data.
    • Data Storage: User IDs on the Ethereum blockchain, content and social graph on the network of hubs.
    • Content Moderation:
      • Currently unclear, potentially delegated to individual applications.
      • Early focus on curated growth through an invitation-only system.
    • Incentives:
      • Short-term reliance on low costs and community enthusiasm.
      • Long-term plans for protocol revenue sharing with hub operators.
    • Ecosystem:
      • Early stage but well-funded.
      • Aiming to balance decentralization with a smooth user experience.

    4. Lens Protocol:

    • Focus: Decentralized social graph that empowers creators and communities.
    • Mechanism:
      • Built on the Polygon blockchain, leveraging its scalability and lower transaction fees.
      • Users own their social graph data as NFTs (non-fungible tokens).
    • Data Storage:
      • Social graph data stored on the Polygon blockchain.
      • Content can be stored on-chain or off-chain using IPFS (InterPlanetary File System).
    • Content Moderation:
      • Can be implemented at the application level or through community governance mechanisms.
    • Incentives:
      • Native token ($LENS) for governance and potential monetization opportunities.
      • Enables new forms of creator monetization through NFTs and social tokens.
    • Ecosystem:
      • Rapidly growing ecosystem of applications and communities.
      • Strong focus on creator empowerment and ownership.

    Conclusion:

    The decentralized social media landscape is evolving rapidly, with each protocol offering a unique approach to address the limitations of centralized platforms. The success of these protocols will depend on their ability to attract users, foster vibrant ecosystems, and navigate the challenges of content moderation and sustainability.

  • 通俗易懂:理解ICE协议及其Java实现ice4j

    引言

    在网络通信中,当涉及到穿越网络地址转换(NAT)设备时,传统的通信协议可能会面临一些挑战。为了解决这个问题,我们需要使用一种特殊的协议来实现穿越NAT设备的功能。其中一种常用的协议是ICE(Interactive Connectivity Establishment)协议,它将STUN(Simple Traversal of UDP through NAT)和TURN(Traversal Using Relays around NAT)等工具结合起来,为基于Offer/Answer的协议(如SIP和XMPP)提供了一种强大的穿越NAT的机制。

    在本文中,我们将介绍ICE协议及其在Java中的实现ice4j。我们将详细讨论ICE协议的原理、作用,以及ice4j项目的特点和用途。让我们一步步深入了解ICE协议及其Java实现ice4j吧!

    ICE协议的原理和作用

    ICE协议是一种用于解决NAT穿越问题的协议。它通过结合STUN和TURN等工具,提供了一种机制来使基于Offer/Answer的协议能够穿越NAT设备。

    ICE协议的核心思想是在通信的两端(称为对等体)之间建立一个可靠的连接。ICE协议通过以下步骤实现穿越NAT的功能:

    1. 收集候选地址:对等体收集自己的IP地址和端口号,并将其作为候选地址。这些候选地址可以是本地的IP地址,也可以是通过STUN服务器获取的公网地址。
    2. 建立连接:对等体之间交换候选地址,然后根据一系列规则和优先级选择最佳的候选地址来建立连接。
    3. NAT穿越:如果对等体之间的直接连接无法建立,ICE协议将尝试使用TURN服务器作为中继来实现穿越NAT。

    通过以上步骤,ICE协议能够有效地解决NAT穿越的问题,确保通信双方能够建立可靠的连接。

    ice4j项目的特点和用途

    ice4j是一个用Java实现的ICE协议库,它提供了一些特色功能和用途,使其成为开发者们首选的ICE协议实现之一。

    1. 简化开发:ice4j提供了一套简单易用的API,使开发者能够快速、方便地集成ICE协议功能到他们的应用程序中。
    2. 支持Pseudo TCP:除了基本的ICE功能,ice4j还支持Pseudo TCP协议,这是一种通过UDP模拟TCP连接的技术。它提供了可靠的数据传输,并通过模拟TCP的流量控制和拥塞控制来优化传输性能。
    3. Socket共享:ice4j支持在多个应用程序之间共享同一个UDP套接字,这样可以有效地减少网络资源的占用。

    通过使用ice4j,开发者们可以轻松地实现ICE协议的功能,从而使他们的应用程序能够在复杂的网络环境中实现可靠的通信。

    ice4j的应用举例

    以下是一些使用ice4j的典型应用场景:

    1. 即时通信应用:ice4j可以用于构建支持实时音视频通信的应用程序,如视频会议、在线聊天等。它能够帮助应用程序穿越NAT设备,实现可靠的点对点通信。
    2. WebRTC应用:WebRTC是一种用于在Web浏览器中实现实时通信的技术,而ICE协议是WebRTC的核心组成部分之一。通过使用ice4j,开发者可以轻松地在WebRTC应用中实现NAT穿越和建立可靠的连接。
    3. 网络游戏:在网络游戏中,玩家之间需要建立可靠的连接以进行实时游戏交互。通过使用ice4j,开发者可以实现游戏服务器和客户端之间的可靠通信,提供流畅的游戏体验。

    总结

    ICE协议及其Java实现ice4j为解决NAT穿越问题提供了一种强大的机制。通过收集候选地址、建立连接和使用中继服务器,ICE协议能够实现可靠的点对点通信。ice4j作为ICE协议的Java实现,提供了简化开发、支持Pseudo TCP和Socket共享等特色功能,使开发者能够轻松地集成ICE协议功能到他们的应用程序中。

    参考文献:

  • ActivityPub:去中心化社交网络协议

    ActivityPub 是一个去中心化的社交网络协议,基于 ActivityStreams 2.0 数据格式。它提供了从客户端到服务器的 API,用于创建、更新和删除内容,以及一个从服务器到服务器的 API,用于传递通知和内容。本文将深入探讨 ActivityPub 的核心概念和实现方式。

    什么是 ActivityPub?

    ActivityPub 是一种标准化的协议,旨在实现去中心化的社交网络。它包括两个主要部分:

    1. 客户端到服务器的协议:允许用户(包括真实用户、机器人和其他自动化进程)通过他们在服务器上的账户与 ActivityPub 通信。这可以通过手机、桌面应用或网页应用实现。
    2. 服务器到服务器的协议:使去中心化网站能够共享信息和内容。

    基本概念

    在 ActivityPub 中,用户通过其在服务器上的账户表示为“actors”。每个 actor 都有一个收件箱(inbox)和发件箱(outbox),用于接收和发送消息。

    {
      "@context": "https://www.w3.org/ns/activitystreams",
      "type": "Person",
      "id": "https://social.example/alyssa/",
      "name": "Alyssa P. Hacker",
      "preferredUsername": "alyssa",
      "summary": "Lisp enthusiast hailing from MIT",
      "inbox": "https://social.example/alyssa/inbox/",
      "outbox": "https://social.example/alyssa/outbox/",
      "followers": "https://social.example/alyssa/followers/",
      "following": "https://social.example/alyssa/following/",
      "liked": "https://social.example/alyssa/liked/"
    }

    客户端到服务器的交互

    客户端通过向 actor 的发件箱(outbox)发送 POST 请求来发布活动。请求必须包含一个 Activity 对象,服务器随后会将其处理并传递到目标收件箱。

    发布活动示例

    假设 Alyssa 想给她的朋友 Ben 发送一条消息,询问他是否还书。她的消息可以表示为一个 ActivityStreams 对象,并通过 POST 请求发送到她的 outbox。

    {
      "@context": "https://www.w3.org/ns/activitystreams",
      "type": "Note",
      "to": ["https://chatty.example/ben/"],
      "attributedTo": "https://social.example/alyssa/",
      "content": "Say, did you finish reading that book I lent you?"
    }

    服务器会将此消息包装在一个 Create 活动中,并将其 POST 到 Ben 的收件箱。

    接收消息

    Alyssa 的手机会通过 GET 请求轮询她的收件箱,以获取新消息。当 Ben 回复了她的消息,她会看到如下内容:

    {
      "@context": "https://www.w3.org/ns/activitystreams",
      "type": "Create",
      "id": "https://chatty.example/ben/p/51086",
      "to": ["https://social.example/alyssa/"],
      "actor": "https://chatty.example/ben/",
      "object": {
        "type": "Note",
        "id": "https://chatty.example/ben/p/51085",
        "attributedTo": "https://chatty.example/ben/",
        "to": ["https://social.example/alyssa/"],
        "inReplyTo": "https://social.example/alyssa/posts/49e2d03d-b53a-4c4c-a95c-94a6abf45a19",
        "content": "<p>Argh, yeah, sorry, I'll get it back to you tomorrow.</p><p>I was reviewing the section on register machines, since it's been a while since I wrote one.</p>"
      }
    }

    服务器到服务器的交互

    服务器之间通过向 actor 的收件箱发送 POST 请求来传递消息。这种交互方式允许去中心化的社交网络跨不同服务器传递信息。

    示例:服务器间的消息传递

    当 Alyssa 发布一条消息到她的 outbox,服务器会查找消息的目标收件箱,并将消息 POST 到这些收件箱。这样,Ben 的服务器就能接收到 Alyssa 的消息,并将其存储在 Ben 的收件箱中。

    安全性与认证

    ActivityPub 使用认证机制来验证客户端与服务器之间、以及服务器与服务器之间的互动。为了确保内容的真实性,服务器应验证接收到的内容,确保其来自声称的 actor,并且该 actor 有权限更新资源。

    验证示例

    服务器在接收到一个活动后,应验证该活动的 idactor 属性,确保其真实性。例如:

    {
      "@context": "https://www.w3.org/ns/activitystreams",
      "type": "Like",
      "actor": "https://example.net/~mallory",
      "to": ["https://hatchat.example/sarah/", "https://example.com/peeps/john/"],
      "object": {
        "@context": {"@language": "en"},
        "id": "https://example.org/~alice/note/23",
        "type": "Note",
        "attributedTo": "https://example.org/~alice",
        "content": "I'm a goat"
      }
    }

    服务器应确保 idactor 属性合法,并查验对象是否由 actor 创建。

    结论

    ActivityPub 通过提供去中心化的社交网络协议,实现了更高的自由度和隐私保护。无论是客户端到服务器的交互,还是服务器到服务器的消息传递,ActivityPub 都为构建去中心化的社交网络提供了强大的工具。

    参考文献

    通过了解和实现 ActivityPub,我们可以构建一个更加自由和开放的互联网社交网络环境。

    image.png

人生梦想 - 关注前沿的计算机技术 acejoy.com 🐾 步子哥の博客 🐾 背多分论坛 🐾 借一步网