\n2021-02-15T09:22:08Z\t@<adi https://twtxt.net/user/adi/twtxt.txt> (#<iwddgwa https://twtxt.net/search?tag=iwddgwa>) thank you!\n2021-02-15T09:22:10Z\t@<adi https://twtxt.net/user/adi/twtxt.txt> (#<iwddgwa https://twtxt.net/search?tag=iwddgwa>) thank you!\n
@<nick url> syntax from the original spec and just using a different prefix @ for mentions # for tags, etc. But this is probably unnecessary as the hashes themselves are content addresses and don't need to be URLs. Hmmm? π€
busybox and finit and write my own init and set of userland. Might be a lot of work though, but it would be fun π
\n\nIt would just be a matter of stripping out the "Twt Subject" out now from the presentation layer. But somehow I don't think @anth is talking about this, or is using an old client with a more bland UX?
twt CLI with something like:\n\n\ngo get github.com/jointwt/twtxt/cmd/twt/...\n
for example as an idea/concept. What do you think @darch?
<angle> brackets like Twt and Twter structures. Thank you! Fixed in 1e42f7d -- We need to build out a more extensive test suite π
MENTION(s) and over 1.7k FOLLOW(s) events. So π€·ββοΈ
twtd (_we haven't renamed the binary yet!_) it _was_ quite difficult to build and implement properly. We do support it though, although I'm not 100% sure it still works. It supports outbound WebMentions(s) as well as inbound to Twt(s) (_we'll be calling them Yarns right? π€£_). So it was possible to -mention someone cross-pod without having to follow them and it would trigger a notif. But OTOH it hasn't really proved all that useful really IHMO..._
description or tagline. This one is important for feeds so we should formalize on it, its completely an optional field, but for rss/atom/news/feeds it becomes quite useful to describe wtf the feed is :)