AT Protocolは、データの所有者をプラットフォームから個人に回帰させた。この構造では任意のデータの共同編集を行えないと言われているが、たとえば特定のキーワードを拾ってずっと保持するフィードを用意する。ここに流れる投稿を、ひとつのデータベースとみなしたら、複数人でその中身を操作しているとみなせないだろうか。
というわけで、私は現在「編集共有」と呼ぶデータベースの新しい更新方法を模索している。これを伝えるには、パーティの買い出しリストを編集する場合が分かりやすい。買い出しリストは、フィードのようにfirehoseの投稿を監視して条件（キーワードや投稿者）に一致するレコードのみ取り上げる。このレコードは編集操作レコードであり、買い出しリストは、レコード自体ではなくこの中身の「300円のコーラを追加」「200円のポテトチップスを追加」「ドーナツを削除」という3件の操作を、問題がなければ採用して背後のデータベースに反映させる。買い出しリストに読み出しが要求されたら、そのデータベースから項目を吐き出す。あるいは、買い出しリストの管理人が接続を許可している、AT Protocol上にない任意のクライアントが、直接データベースを読みだして独自に表示しても構わない。
私もこれを用いたAppViewを開発中だが、もしこれを見て何か思いついたものがあれば、いっそ先に完成させて実際にどう動くのか見せてほしい。
余談だが、これを今回のAppViewに対応したクライアント側で表示するときに、もし内容が「買い出しリスト」だけなら問題ないが、通常はより多様な内容に対応したいはずなので、データの任意のキーとUIを結びつける「ひな型」の概念を導入したい。ひな型は主にクライアント側で定義され、買い出しリストなどは読み出し操作の際に、自分が吐き出すデータがどのようなひな型に対応しているのかの名前の一覧を、親子関係を持つオブジェクトで示し、クライアント側は対応する中で最も子（自身のデータに特化したひな型）のひな型を採用してUIに反映する。この親子関係は、ひな型名の情報のみを持つことから祖先からの派生関係をすべて記述する必要はないため、必要以上に膨らまないようにできる。
個人的な開発の書き留めのようになってしまったものの、役立ったら嬉しい。