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!

@shreyan@twtxt.net This is a brilliant idea! 💡I’ve got ideas too! I’d like to even share/borrow some ideas from some of the work we did in Salty IM too 👌 – What have you got in mind? – As an aside, it might also be worth (finally?) just re-imagining Twtxt? (perhaps we can still support the old legacy twtxt though but keep it completely a separate thing design/software wise?)

We can start this thread off by listing some ofd the problems that exist today:

• There is no identity of a feed per se. This makes moving feeds to another location hard(er).
  
• There is no way to notify a feed in any way (e.g: @-mention someone) – It’s a 1-way street.
  
• what else?

@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

I agree with @sorenpeter@darch.dk. WebFinger and WebMentions are very much in the spirit of Twtxt and both of them are already in use. If we’re going to do much more than that, we should probably just use Nostr instead.

@mckinley@twtxt.net Also agree, and yarnd already employes the use of WebMentions, WebSub and WebFinger. So maybe this thread can just be about a) documenting/designing the protocol b) building a new Yarn backend and c) Building a new reference frontend?

yarnd does not do auto discovery via webfinger though.. i cant put @username and have it fetch the feed url from webfinger. to fully make feeds portable. would also need to be able to use that for hashing.

@prologic@twtxt.net I know yarn is culturally a slower place than most mainstream social, but I would like to enable servers to somewhat “broadcast” new events on some subscribable endpoint. Since much of the network relies on indexers, this would help the indexers get new posts more immediately, rather than having to schedule their crawls. That’s just one idea to start with

@shreyan@twtxt.net Ahh Yarn already does this! It uses WebSub and posts between instances appear almost immediately 🤣

@prologic@twtxt.net Cool! Now what might be useful is to take all the cool things Yarn does and spec them out into a full protocol. This is also where we might get into extending beyond what Twtxt can offer and into a yarn-specific spec.

@shreyan@twtxt.net Yeah that’s what I would focus on personally. Document the API and spec out the protocol(s).

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