💡 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

An example feed would look like this:

{
    "name": "prologic",
    "desc": "\"Problems are Solved by Method\" 🇦🇺👨‍💻👨‍🦯🏹♔ 🏓⚯ 👨‍👩‍👧‍👧🛥 -- James Mills (operator of twtxt.net / creator of Yarn.social 🧶)",
    "key": "kex17m00vqjduqlf6j5xcvtpyhk2zg3shv2x8r5qzyancjlhgl4ytj8slvt7h0",
    "links": [
        {
            "title": "My CV",
            "href": "https://prologic.shortcircuit.net.au/"
        }, 
        {
            "title": "My Projects",
            "href": "https://git.mills.io/prologic"
        },
        {
            "title": "My Github profile (@prologic)",
            "href": "https://github.com/prologic"
        }
    ],
    "items": [
        {
            "id": "https://yarn.mills.io/permalink/xt2mrjwfmwlh6xrcoom7ywpmg6hdrduy56cvzjoi76ibdjjiycwa",
            "hash": "xt2mrjwfmwlh6xrcoom7ywpmg6hdrduy56cvzjoi76ibdjjiycwa",
            "sig": "3vdKTvI_WGDcM_cUUPGmWHPFpZ9IpORgFkhVFndcxbuUm3XF2w895nEvh2CIA0P3OekfmW6pWQP4wSsXZSCMAA",
            "format": "text/markdown",
            "time": "2023-04-16T11:04:28+10:00",
            "content": "Hello World"
        }
    ]
}

Blah I forgot Avatar, but that could be icon I guess or image.

@prologic@twtxt.net 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.

@marado@twtxt.net 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.

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.

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.

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

@prologic@twtxt.net 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.

@darch@neotxt.dk 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.