@kas@enotty.dk that sounds fair to me.

Additionally, there’s a lot that can be done by a client to reduce the network traffic and UI latency of twtxt without changing the protocol.

@mdom@domgoergen.com, @kas@enotty.dk re: metadata, I’m (obviously) in favor of my suggestion for metadata-in-comments, but I don’t think we should have comments in comments.

@mdom@domgoergen.com, @dave@davebucklin.com, @kas@enotty.dk I agree with the “no max length; show at least 140chars” idea.

I’m not working on bussard, I’m just IRC friends with @technomancy@technomancy.us and he expressed interest in making scheme available there.

@mdom@domgoergen.com mostly for fun, but once I have it working more it’ll get integrated into https://gitlab.com/technomancy/bussard.

Popular, finally. https://github.com/mdom/we-are-twtxt/ – Now exploring client options.

Just setting up my twtxt

@mdom@domgoergen.com @kas@enotty.dk thanks! I was checking access logs on nginx and noticed a bunch of 404s to my twtxt url, so I decided to pick it back up.

Think I’ll try out twtxt again for while…

How should metadata about a twtxt feed be stored? Weigh in @ https://github.com/buckket/twtxt/issues/48

part 3: make ‘tf’ run ‘twtxt follow “$@”’

part 2: make ‘tw’ run ‘twtxt tweet “$@”’

twtxt-able twtxt helper scripts, part 1: make ‘tt’ run ‘twtxt timeline -l 1000 | less’

I find the wide variety of ways people are deploying twtxt pretty fascinating

Been thinking about writing a twtxt-AAS provider.