(#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`.

(#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.

(#oyi5iua) @marado See, even if we (for example) did something to change the behaviour of `yarnd` such that it: 1. produced a `twtxt.txt` feed that stripped `\u2028` so all posts are single-line. 2. converted Markdown to "plain text" 3. limited posts to 140 characters Would this make few that scream and shout the loudest happier that Yarn is more _properly_ using Twtxt? 🤔 Would Yarn _then_ be considered to be using Twtxt as-it-is/was intended? 🤔 Of course this would have the side effect of: - Your longer posts would now be truncated and meaningless. - Posting links to images would no longer work. - Threading would no non-existent. And so we're back to square one, where Twtxt as-it-was-is intended is a spec that whilst on its own useful for a very limited number of use-cases it lacks certain features that make microBlogging and interacting with others viable.