DiscussKit, Rebuilt on ARC

ArcBlock Community has moved to ARC with its existing posts, replies and community identities intact. DiscussKit, the product behind it, has been rebuilt on ARC, the Agentic Realm Computer.
This is more than moving an old application onto a new runtime. The product is still called DiscussKit, and it still handles posts, replies and conversations around content. Underneath, however, the old and new versions are two different implementations. The old one was a large Web application. The new one lets ARC provide identity, data spaces, indexing and shared interface capabilities, while DiscussKit focuses again on discussion.
It is a major update and a new division of responsibility. Community members can continue where they left off, while the way discussions are stored, owned and reused has changed underneath.
It began at an internal hackathon
DiscussKit began at an ArcBlock internal hackathon. For one week, the whole team took the position of outside developers and built products on our own Blocklet Server. The first DiscussKit was a simple forum, and it won the hackathon.
A forum was not a new idea. What made the project worth continuing was a structural observation. Forum threads, blog comments, replies under a photo, annotations on a document and discussions attached to an object in a design tool may look like different products, but their information shapes are closely related. Each begins with some primary content, followed by responses that can branch or attach to a particular object or location.
That is the kind of common structure a Blocklet should make reusable. We did not want a separate, nearly identical system for blogs, bulletin boards, comments, annotations and gallery discussions. DiscussKit grew from a forum into a configurable content and collaboration component.
It became a remarkably versatile application. During the Blocklet Server era, DiscussKit included discussions, blogs, documentation, bookmarks and Web chat. It supported boards, tags, full-text search, reactions, permissions and action history. ArcBlock's website, internal collaboration spaces and ArcBlock Community all used it. A common site combination was Pages Kit plus DiscussKit: one built the pages, while the other handled content and community interaction.

DiscussKit during the Blocklet Server era, from the 2024 Discuss Kit v2.0 release.
That abstraction made DiscussKit reusable, but it also gave one application too many responsibilities. We did not want to carry the entire bundle unchanged into ARC.
The new version begins by doing less
The new DiscussKit returns to three core forms: a discussion board, comments and annotations. It handles posts, replies, categories, reactions, search and discussion attached to another object. It no longer tries to be a blog engine, documentation system, bookmark manager and chat service at the same time.
Static pages, articles and documentation are now native capabilities of ARC Web Device, expressed through content in AFS and pages in AUP. Real-time messaging overlaps with discussion, but its pace, notifications and scaling needs make it a separate service in ARC. This lets DiscussKit focus on the discussion capability that applications actually need to reuse.
The smaller scope gives DiscussKit a clearer product boundary. Any Blocklet that needs a discussion area, a comment surface or collaboration attached to a piece of content can reuse the same discussion capability.
The new version may therefore look smaller without being a downgrade. Much of the foundation DiscussKit once had to implement for itself now belongs to ARC.
From an application database to ARC data spaces
The old DiscussKit was a conventional Web application. It owned its application logic and user interface, while posts, comments, tags and permissions lived in an application database, usually SQLite by default. That model was familiar and dependable, and it served DiscussKit well on Blocklet Server.
The difficult questions appeared around data ownership and cooperation between instances. When a post exists only inside one forum's database, the operator can moderate it, but the author does not naturally keep an independent copy. Another DiscussKit instance that wants to recognize the same author, refer to the same content or participate in federation must first solve identity, replication, conflict handling and indexing.
The new DiscussKit declares the shape of posts and comments in ARC, then writes them into spaces through AFS, the Agentic File System. The relationship is straightforward: ARC is the runtime, AFS is its unified data-resource layer, and ArcSpace puts those data spaces in users' hands.
The current implementation uses ARC's replicated collection capability. Take a single post: Community needs a record it can display, search and moderate, while the author's user space retains a mirror copy. DID identifies the author. ARC provides permissions, replication and indexing. DiscussKit determines how the discussion looks and behaves. This data model establishes an author-held copy; it does not mean the complete cross-instance migration and synchronization experience is finished.
| Blocklet Server era | ARC era |
|---|---|
| DiscussKit maintained its application database | The data shape is declared in ARC and carried by AFS and spaces |
| Identity, permissions and search were integrated by the application | DID, access control and the instance index are runtime capabilities |
| One instance stored the community record | The instance space keeps the community record while the author's user space retains a mirror copy |
| The front end and application logic were tightly coupled | Pages are expressed in AUP, and post and comment capabilities can be reused by other Blocklets |
A data space can include files, structured records, full-text indexes and vector indexes. Developers work with one AFS resource surface instead of building separate storage for bodies, attachments, indexes and personal copies.
This structure gives our long-running decentralized social software idea a practical foundation. Discovery between instances, synchronization, moderation and conflict policies still require more work. What has changed today is the data model: the community retains a record it can manage, while the author's space can retain a copy.
Community is the proof of this migration
Architecture matters when it carries a real service. ArcBlock Community ran on Blocklet Server for years and is one of the longest-running, most demanding uses of DiscussKit. It contains historical posts, replies, boards, tags, user identities and new discussions that continue to arrive.
www.arcblock.community is now served by the new DiscussKit on ARC. Existing content has been migrated, and members can continue to browse boards, search posts, sign in, start discussions and reply. For community members, this should feel like a quiet transition. For us, it proves something specific: ARC can serve continuously written user-generated community content, not only static sites.

ArcBlock Community, captured in September 2026.
The simplest way to use the release is to visit Community. Guests can browse public discussions. After signing in, members can post, reply and react. Developers can also study DiscussKit as an ARC Blocklet reference for how posts, comments, replicated collections and AUP pages fit together.
What discussion can connect to next
The old DiscussKit added blockchain features such as tips at the application layer. ARC changes that boundary. Chain capabilities can be mounted explicitly by the runtime, so DiscussKit does not need to maintain a separate integration for ArcBlock Chain, Ethereum or every future network.
That creates room for later work. A community contribution could be associated with a badge or Verifiable Credential. Membership and access could be expressed with verifiable credentials. Suitable communities could add tips, digital assets or verifiable records. These are directions we are continuing to build, not features delivered by this migration. Each one must make authorization, visibility and moderation boundaries clear before it becomes part of the product.
The nearer-term opportunity is to make discussion reusable across ARC applications. A product page can have its own discussion. An object inside a dashboard can accept comments. A paragraph in a document can carry an annotation. None of these should require installing an entire forum.
What this release does not include
This release focuses on discussion boards, posts, comments, reactions, categories, search and migration of the existing Community content. The old blog, documentation, bookmark and chat modules have not been copied into the new DiscussKit. ARC Web Device or future dedicated capabilities will carry those responsibilities.
User-data mirrors are part of the new data model, but the complete cross-instance federation experience is still being built. Richer interactions involving blockchains, credentials and digital assets are also future work. We will demonstrate each one through working product behavior.
The new DiscussKit still lets people discuss content. The difference is that it no longer has to carry its own database, identity system, index and entire content platform everywhere it goes. Discussion can attach to a product page, an application object or a paragraph in a document without rebuilding a forum for each setting.
This time, DiscussKit is smaller. It can fit in many more places.
Related links
このページに関わるもの
製品
-
ARC
active
Blocklet のランタイム。Blocklet として記述されたアプリケーションを、その Blocklet が必要と宣言したリソースとともに実行する場所を開発者に提供します。
-
ARC Space
active
DID に紐づくデータ空間。個人用の空間を作ることも、あるタスクが必要とする権限とデータモデルでアプリケーションを接続することもできます。
-
DiscussKit
active
ARC 上で再構築された再利用可能なディスカッションコンポーネント。投稿、コメント、カテゴリー、リアクション、検索を備え、ArcBlock Community を支えています。
用語
-
AFS
AFS(Agentic File System)は、タスクに関係するファイル、サービス、実行中の作業を確認可能なリソース表示にします。agent に区別のないマシンや API の束を渡すのではなく、名前と境界を持つ作業世界を与えます。
-
AUP
AUP(Agentic UI Protocol)は、アプリケーションが何を表示し、どの操作を可能にするかを表現します。runtime はデバイス能力に合う部分を render し、一つの画面の pixel をアプリケーションそのものとして扱いません。
-
Blocklet
Blocklet は ARC の deployable unit です。アプリケーションが宣言する content、configuration、runtime の要件を一緒に保ち、実行する単位を理解し管理しやすくします。
-
DID
DID はデジタル識別子です。保持者と検証者が、そのアイデンティティを誰が管理し、ある主張が誰に関わるかを確認するために使います。DID はウォレットではなく、アプリケーションのアカウント、サインイン方法、権限ルールを置き換えるものではありません。