(#oyi5iua) @xuu Yeah this is a great idea👌 I was just thinking of the storage format and what clients would fetch as a resource 🤔

(#oyi5iua) @prologic I probably would *not* use an yarn.social client/app that didn't deal with twtxt (text) feeds - both "follow" them and "publish" them. But I suppose that it is possible to have a bidirectional converter between that json format and twtxt.

(#oyi5iua) @prologic Having to deal with json and cryptography is not very appealing to me. It's the simplicity and hackability of twtxt.txt that I'm drawn by. That you can in fact handwrite your posts and you can throw pretty much anything at it after the datetime+tab and it still being somewhat human readable and work in most clients. If you do something that a client does not like, then you will have to take up the debate with the devs or make your own. And if people like some features that you invented, then your new client might get more users, or your end up doing something just or for yourself.

(#oyi5iua) I'm not super a fan of using json. I feel we could still use text as the medium. Maybe a modified version to fix any weakness. What if instead of signing each twt individually we generated a merkle tree using the twt hashes? Then a signature of the root hash. This would ensure the full stream of twts are intact with a minimal overhead. With the added bonus of helping clients identify missing twts when syncing/gossiping. Have two endpoints. One as the webfinger to link profile details and avatar like you posted. And the signature for the merkleroot twt. And the other a pageable stream of twts. Or individual twts/merkle branch to incrementally access twt feeds.

(#oyi5iua) @darch I think having a way to layer on features so those who can support/desire them can. It would be best for the community to be able to layer on (or off) the features.

(#oyi5iua) I'm not super a fan of using json. I feel we could still use text as the medium. Maybe a modified version to fix any weakness. What if instead of signing each twt individually we generated a merkle tree using the twt hashes? Then a signature of the root hash. This would ensure the full stream of twts are intact with a minimal overhead. With the added bonus of helping clients identify missing twts when syncing/gossiping. Have two endpoints. One as the webfinger to link profile details and avatar like you posted. And the signature for the merkleroot twt. And the other a pageable stream of twts. Or individual twts/merkle branch to incrementally access twt feeds.

(#oyi5iua) Blah I forgot Avatar, but that _could_ be `icon` I guess or `image`.

💡 **Quick 'n Dirty prototype Yarn.social protocol/spec:** > If we were to decide to write a new spec/protocol, what would it look like? Here's my rough draft (_back of paper napkin idea_): - Feeds are JSON file(s) fetchable by standard HTTP clients over TLS - WebFinger is used at the root of a user's domain (or multi-user) lookup. e.g: `prologic@mills.io` -> `https://yarn.mills.io/~prologic.json` - Feeds contain similar metadata that we're familiar with: Nick, Avatar, Description, etc - Feed items are signed with a ED25519 private key. That is all "posts" are cryptographically signed. - Feed items continue to use content-addressing, but use the full Blake2b Base64 encoded hash. - Edited feed items produce an "Edited" item so that clients can easily follow Edits. - Deleted feed items produced a "Deleted" item so that clients can easily delete cached items. #Yarn.social #Protocol #Ideas

(#oyi5iua) Son in theory we _could_ have a `yarn.txt` feed and a stripped-down and limited `twtxt.txt` feed. But I am 98% convinced this wouldn't solve any of the perceived problems, actually I'm 100% certain. Mostly because there are no offered solutions, no actionable feedback, no contributions, just complains and arguments.

(#oyi5iua) @prologic I probably would *not* use an yarn.social client/app that didn't deal with twtxt (text) feeds - both "follow" them and "publish" them. But I suppose that it is possible to have a bidirectional converter between that json format and twtxt.