So where do we start wring down the specs/protocol for twtxt2/yarn?

@shreyan@twtxt.net What do you mean when you say federation protocol?

• Either use webfinger for identity like mastodon etc. or use ATproto from Bluesky (or both?)

• We can use webmentions or create our own twt-mentions for notifying someones feed (WIP code at: https://github.com/sorenpeter/timeline/tree/webmention/views)

I’m not sure we need much else. I would not even bother with encryption since other platforms does that better, and for me twtxt/yarn/timeline is for making things public

yarn should define its own federation protocol that extends the basic twtxt in ways that twtxt doesn’t allow. it’s time. and i’ve got ideas!

I would love to see a world where ones twtxt feed is defined by webfinger. So @xuu@txt.sour.is => https://text.sour.is/user/xuu/twtxt.txt

Then my identity can exist independent of the feed location. And I can host multiple protocol types for my feed. Ie. http/gopher/Gemini/irc DCC/etc

I’m also more in favor of #reposts being human readable and writable. A client might implement a bottom that posts something simple like: #repost Look at this cool stuff, because bla bla [alt](url)

This will then make it possible to also “repost” stuff from other platforms/protocols.

The reader part of a client, can then render a preview of the link, which we talked about would be a nice (optional) feature to have in yarnd.

Pensée désagréable du jour: le protocole #gemini n’est pas écologique car il n’est pas accessible sur du vieux matériel à cause du TLS forcé. Servir des fichiers textes écrits en gemtext en #http est mieux dans ce cas

Check out the Nex Protocol. It’s designed to be even simpler than Gemini and Gopher. What do you think? Could be great to host a twtxt feed on.

Can’t wait until this site joins the trend and becomes “y.com” - the everything protocol.

@prologic@twtxt.net hmm, I’d be up for thinking about that. At least at the protocol and design level–I’m afraid I can’t help much with Go programming.

@prologic@twtxt.net I’ve not looked into the Bluesky protocol, so I don’t know what to think specifically. But this guy definitely is not impressed lol

Sam Wight :verified:: “Fucking Christ the @protocol i…” - Urbanists.Social

Incredible critique of the protocol Bluesky is creating. It sounds like s shitshow.

💡 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

I played around with parsers. This time I experimented with parser combinators for twt message text tokenization. Basically, extract mentions, subjects, URLs, media and regular text. It’s kinda nice, although my solution is not completely elegant, I have to say. Especially my communication protocol between different steps for intermediate results is really ugly. Not sure about performance, I reckon a hand-written state machine parser would be quite a bit faster. I need to write a second parser and then benchmark them.

lexer.go and newparser.go resemble the parser combinators: https://git.isobeef.org/lyse/tt2/-/commit/4d481acad0213771fe5804917576388f51c340c0 It’s far from finished yet.

The first attempt in parser.go doesn’t work as my backtracking is not accounted for, I noticed only later, that I have to do that. With twt message texts there is no real error in parsing. Just regular text as a “fallback”. So it works a bit differently than parsing a real language. No error reporting required, except maybe for debugging. My goal was to port my Python code as closely as possible. But then the runes in the string gave me a bit of a headache, so I thought I just build myself a nice reader abstraction. When I noticed the missing backtracking, I then decided to give parser combinators a try instead of improving on my look ahead reader. It only later occurred to me, that I could have just used a rune slice instead of a string. With that, porting the Python code should have been straightforward.

Yeah, all this doesn’t probably make sense, unless you look at the code. And even then, you have to learn the ropes a bit. Sorry for the noise. :-)

Asking Scientists Questions
⌘ Read more

You need better pen test scripts. :-) Seriously, the protocol is absurdly simple. Turn it on! Don’t trust any of the implementations? Write your own!

i want to use something similar to ssb producer tokens as the basis for novo atlantis trade protocols. interfacing with scarcity currencies has been a headache, but i think something like taller that does delegated settlement can link coop credits to another currency for foreign trade could work. devil is in the details.

What if due to climate crisis effects and disasters our digital future will depend on low-energy hardware and protocols like Gemini?

Protocol is a virtual writing surface and a mirror. Memory takes a copy and then Forgets.

i’m going to be honest with you here: i despise protocol labs. IPFS/FileCoin is a scam. fuck that shit.

Indeed! I think the first “network protocol client” I ever wrote was something that just did the PING/PONG part and passed everything else raw.

No, totally not useful. 🤣 I mean, the finger protocol is pretty trivial, and it’d be fun to add, but doesn’t replace anything you’re doing.

email-based gossip protocol :ac_mischief:

interesting RFC dated April 1st, 1998: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0):

https://tools.ietf.org/html/rfc2324

looking at the date this was published, i think the authors originally meant this as an apil’s fool joke/prank.

funny because now we have IOTs and this is somewhat a reality today :P

I’m unclear if I’m going to do the twtxt.net discovery protocol; neither my web server nor Plan 9’s default capture agent strings. :-/

@prologic@twtxt.net the HKP is http keyserver protocol. it’s what happens when you do gpg --send-keys

makes a POST to the keyserver with your pubkey.

Enjoying the constraints of the Gopher protocol as a minimalistic zen-mode kind of online publishing revival.