@prologic@twtxt.netYes, I think tags should just be #foo, and let the client figure out searching if it cares.
@movq@www.uninformativ.de No argument that threading is an improvement. But I think (#hash) does that, and I think figuring out how to search should mostly be up to the client.
Hah… my silly twtxt client now has “stories” mode.☺
@prologic@twtxt.net deedum for android.
Kristall for OS X
Elaho for iOS
though I can only vouch for the first two.
I have a working model for the reader portion of what I want this twtxt client to do.
Can we not have clients sign their own public keys before listing them on their Pod’s account?
Yeah.. we probably could. when they setup an account they create a master key that signs any subsequent keys. or chain of signatures like keybase does.
@prologic@twtxt.net (#gqg3gea) ha yeah. COVID makes for a timey-wimey mish-mash. Worked on some WKD and fought with my XMPP client a bit.
@prologic@twtxt.net huh.. true.. the email is md5/sha256 before storing.. if twtxt acted as provider you would store that hash and point the SRV record to the pod. .. to act as a client it would need to store the hash and the server that hosts the image.
@kas@enotty.dk [re: gopher client] If you happen to be on Windows, then Gopher Browser for Windows by Matt Owen is pretty nice, otherwise I use Lynx indeed for gopher.
@von@tilde.town having topic-specific twtxt feeds is not a silly idea. Not sure if the clients allow easy switching though.
Made my own super basic twtxt client in 3 lines of code as a bashrc function. #l33t
Added clients and articles sections and added domgoergen’s twtxt.txt to https://indieweb.org/twtxt
// todo Create a Kaios client for twtxt
@kas@enotty.dk I liked the idea that the reader’s client should enforce the length limit.