@mckinley@twtxt.net To answer some of your questions:

Are SSH signatures standardized and are there robust software libraries that can handle them? We’ll need a library in at least Python and Go to provide verified feed support with the currently used clients.

We already have this. Ed25519 libraries exist for all major languages. Aside from using ssh-keygen -Y sign and ssh-keygen -Y verify, you can also use the salty CLI itself (https://git.mills.io/prologic/salty), and I’m sure there are other command-line tools that could be used too.

If we all implemented this, every twt hash would suddenly change and every conversation thread we’ve ever had would at least lose its opening post.

Yes. This would happen, so we’d have to make a decision around this, either a) a cut-off point or b) some way to progressively transition.

🧮 USERS:1 FEEDS:2 TWTS:1087 ARCHIVED:78676 CACHE:2491 FOLLOWERS:17 FOLLOWING:14

@lyse@lyse.isobeef.org This looks like a nice way to do it.

Another thought: if clients can’t agree on the url (for example, if we switch to this new way, but some old clients still do it the old way), that could be mitigated by computing many hashes for each twt: one for every url in the feed. So, if a feed has three URLs, every twt is associated with three hashes when it comes time to put threads together.

A client stills need to choose one url to use for the hash when composing a reply, but this might add some breathing room if there’s a period when clients are doing different things.

(From what I understand of jenny, this would be difficult to implement there since each pseudo-email can only have one msgid to match to the in-reply-to headers. I don’t know about other clients.)

@movq@www.uninformativ.de Another idea: just hash the feed url and time, without the message content. And don’t twt more than once per second.

Maybe you could even just use the time, and rely on @-mentions to disambiguate. Not sure how that would work out.

Though I kind of like the idea of twts being immutable. At least, it’s clear which version of a twt you’re replying to (assuming nobody is engineering hash collisions).

@prologic@twtxt.net Some criticisms and a possible alternative direction:

1. Key rotation. I’m not a security person, but my understanding is that it’s good to be able to give keys an expiry date and replace them with new ones periodically.

2. It makes maintaining a feed more complicated. Now instead of just needing to put a file on a web server (and scan the logs for user agents) I also need to do this. What brought me to twtxt was its radical simplicity.

Instead, maybe we should think about a way to allow old urls to be rotated out? Like, my metadata could somehow say that X used to be my primary URL, but going forward from date D onward my primary url is Y. (Or, if you really want to use public key cryptography, maybe something similar could be used for key rotation there.)

It’s nice that your scheme would add a way to verify the twts you download, but https is supposed to do that anyway. If you don’t trust https to do that (maybe you don’t like relying on root CAs?) then maybe your preferred solution should be reflected by your primary feed url. E.g. if you prefer the security offered by IPFS, then maybe an IPNS url would do the trick. The fact that feed locations are URLs gives some flexibility. (But then rotation is still an issue, if I understand ipns right.)

On the Subject of Feed Identities; I propose the following:

1. Generate a Private/Public ED25519 key pair
   
2. Use this key pair to sign your Twtxt feed
   
3. Use it as your feed’s identity in place of # url = as # key = ...
   

For example:

$ ssh-keygen -f prologic@twtxt.net
$ ssh-keygen -Y sign -n prologic@twtxt.net -f prologic@twtxt.net twtxt.txt

And your feed would looke like:

# nick        = prologic
# key         = SHA256:23OiSfuPC4zT0lVh1Y+XKh+KjP59brhZfxFHIYZkbZs
# sig         = twtxt.txt.sig
# prev        = j6bmlgq twtxt.txt/1
# avatar      = https://twtxt.net/user/prologic/avatar#gdoicerjkh3nynyxnxawwwkearr4qllkoevtwb3req4hojx5z43q
# description = "Problems are Solved by Method" 🇦🇺👨‍💻👨‍🦯🏹♔ 🏓⚯ 👨‍👩‍👧‍👧🛥 -- James Mills (operator of twtxt.net / creator of Yarn.social 🧶)

2024-06-14T18:22:17Z	(#nef6byq) @<bender https://twtxt.net/user/bender/twtxt.txt>  Hehe thanks! 😅 Still gotta sort out some other bugs, but that's tomorrows job 🤞
...

Twt Hash extension would change of course to use a feed’s ED25519 public key fingerprint.

@bender@twtxt.net Yes, they do 🤣 Implicitly, or threading would never work at all 😅 Nor lookups 🤣 They are used as keys. Think of them like a primary key in a database or index. I totally get where you’re coming from, but there are trade-offs with using Message/Thread Ids as opposed to Content Addressing (like we do) and I believe we would just encounter other problems by doing so.

My money is on extending the Twt Subject extension to support more (optional) advanced “subjects”; i.e: indicating you edited a Twt you already published in your feed as @falsifian@www.falsifian.org indicated 👌

Then we have a secondary (bure much rarer) problem of the “identity” of a feed in the first place. Using the URL you fetch the feed from as @lyse@lyse.isobeef.org ’s client tt seems to do or using the # url = metadata field as every other client does (according to the spec) is problematic when you decide to change where you host your feed. In fact the spec says:

Users are advised to not change the first one of their urls. If they move their feed to a new URL, they should add this new URL as a new url field.

See Choosing the Feed URL – This is one of our longest debates and challenges, and I think (_I suspect along with @xuu@txt.sour.is _) that the right way to solve this is to use public/private key(s) where you actually have a public key fingerprint as your feed’s unique identity that never changes.

🧮 USERS:1 FEEDS:2 TWTS:1086 ARCHIVED:78278 CACHE:2434 FOLLOWERS:17 FOLLOWING:14

@movq@www.uninformativ.de @prologic@twtxt.net Another option would be: when you edit a twt, prefix the new one with (#[old hash]) and some indication that it’s an edited version of the original tweet with that hash. E.g. if the hash used to be abcd123, the new version should start “(#abcd123) (redit)”.

What I like about this is that clients that don’t know this convention will still stick it in the same thread. And I feel it’s in the spirit of the old pre-hash (subject) convention, though that’s before my time.

I guess it may not work when the edited twt itself is a reply, and there are replies to it. Maybe that could be solved by letting twts have more than one (subject) prefix.

But the great thing about the current system is that nobody can spoof message IDs.

I don’t think twtxt hashes are long enough to prevent spoofing.

All this hash breakage made me wonder if we should try to introduce “message IDs” after all. 😅

But the great thing about the current system is that nobody can spoof message IDs. 🤔 When you think about it, message IDs in e-mails only work because (almost) everybody plays fair. Nothing stops me from using the same Message-ID header in each and every mail, that would break e-mail threading all the time.

In Yarn, twt hashes are derived from twt content and feed metadata. That is pretty elegant and I’d hate see us lose that property.

If we wanted to allow editing twts, we could do something like this:

2024-09-05T13:37:40+00:00   (~mp6ox4a) Hello world!

Here, mp6ox4a would be a “partial hash”: To get the actual hash of this twt, you’d concatenate the feed’s URL and mp6ox4a and get, say, hlnw5ha. (Pretty similar to the current system.) When people reply to this twt, they would have to do this:

2024-09-05T14:57:14+00:00	(~bpt74ka) (<a href="https://txt.sour.is/search?q=%23hlnw5ha">#hlnw5ha</a>) Yes, hello!

That second twt has a partial hash of bpt74ka and is a reply to the full hash hlnw5ha. The author of the “Hello world!” twt could then edit their twt and change it to 2024-09-05T13:37:40+00:00 (~mp6ox4a) Hello friends! or whatever. Threading wouldn’t break.

Would this be worth it? It’s certainly not backwards-compatible. 😂

🧮 USERS:1 FEEDS:2 TWTS:1085 ARCHIVED:78244 CACHE:2417 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1084 ARCHIVED:78231 CACHE:2434 FOLLOWERS:17 FOLLOWING:14

@prologic@twtxt.net Perfect, thanks. For my own future reference: curl -H ‘Accept: application/json’ https://twtxt.net/twt/st3wsda

@prologic@twtxt.net Specifically, I could view yarnd’s copy here, but only as rendered for a human to view: https://twtxt.net/twt/st3wsda

@movq@www.uninformativ.de thanks for getting to the bottom of it. @prologic@twtxt.net is there a way to view yarnd’s copy of the raw twt? The edit didn’t result in a visible change; being able to see what yarnd originally downloaded would have helped me debug.

@bender@twtxt.net On twtxt, I follow all feeds that I can find (there are some exceptions, of course). There’s so little going on in general, it hardly matters. 😅

And I just realized: Mutt’s layout helps a lot. Skimming over new twts is really easy and it’s not a big loss if there are a couple of shitposts™ in my “timeline”. This is very different from Mastodon (both the default web UI and all clients I’ve tried), where the timeline is always huge. Posts take up a lot of space on screen. Makes me think twice if I want to follow someone or not. 😅

(I mostly only follow Hashtags on Mastodon anyway. It’s more interesting that way.)

@prologic@twtxt.net One of your twts begins with (#st3wsda): https://twtxt.net/twt/bot5z4q

Based on the twtxt.net web UI, it seems to be in reply to a twt by @cuaxolotl@sunshinegardens.org which begins “I’ve been sketching out…”.

But jenny thinks the hash of that twt is 6mdqxrq. At least, there’s a very twt in their feed with that hash that has the same text as appears on yarn.social (except with ‘ instead of ’).

Based on this, it appears jenny and yarnd disagree about the hash of the twt, or perhaps the twt was edited (though I can’t see any difference, assuming ’ vs ’ is just a rendering choice).

@prologic@twtxt.net I believe you when you say registries as designed today do not crawl. But when I first read the spec, it conjured in my mind a search engine. Now I don’t know how things work out in practice, but just based on reading, I don’t see why it can’t be an API for a crawling search engine. (In fact I don’t see anything in the spec indicating registry servers shouldn’t crawl.)

(I also noticed that https://twtxt.readthedocs.io/en/latest/user/registry.html recommends “The registries should sync each others user list by using the users endpoint”. If I understood that right, registering with one should be enough to appear on others, even if they don’t crawl.)

Does yarnd provide an API for finding twts? Is it similar?

I just manually followed the steps at https://dev.twtxt.net/doc/twthashextension.html and got 6mdqxrq. I wonder what happened. Did @cuaxolo@sunshinegardens.org edit the twt in some subtle way after twtxt.net downloaded it? I couldn’t spot a diff, other than ‘ appearing as ’ on yarn.social, which I assume is a transformation done by twtxt.net.

@prologic@twtxt.net How does yarn.social’s API fix the problem of centralization? I still need to know whose API to use.

Say I see a twt beginning (#hash) and I want to look up the start of the thread. Is the idea that if that twt is hosted by a a yarn.social pod, it is likely to know the thread start, so I should query that particular pod for the hash? But what if no yarn.social pods are involved?

The community seems small enough that a registry server should be able to keep up, and I can have a couple of others as backups. Or I could crawl the list of feeds followed by whoever emitted the twt that prompted my query.

I have successfully used registry servers a little bit, e.g. to find a feed that mentioned a tag I was interested in. Was even thinking of making my own, if I get bored of my too many other projects :-)

@movq@www.uninformativ.de Thanks, it works!

But when I tried it out on a twt from @prologic@twtxt.net, I discovered jenny and yarn.social seem to disagree about the hash of this twt: https://twtxt.net/twt/st3wsda . jenny assigned it a hash of 6mdqxrq but the URL and prologic’s reply suggest yarn.social thinks the hash is st3wsda. (And as a result, jenny –fetch-context didn’t work on prologic’s twt.)

🧮 USERS:1 FEEDS:2 TWTS:1083 ARCHIVED:78202 CACHE:2449 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1082 ARCHIVED:78194 CACHE:2455 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1081 ARCHIVED:78172 CACHE:2486 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1080 ARCHIVED:78169 CACHE:2484 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1079 ARCHIVED:78129 CACHE:2461 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1078 ARCHIVED:78117 CACHE:2455 FOLLOWERS:17 FOLLOWING:14

@movq@www.uninformativ.de I think you are worrying about a non-issue. I see nothing to do on your example twt, because there is no context. Furthermore, if I wanted to follow the feed, everything I need is already on that twt example. :-)

🧮 USERS:1 FEEDS:2 TWTS:1077 ARCHIVED:78103 CACHE:2449 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1076 ARCHIVED:77763 CACHE:2433 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1075 ARCHIVED:77751 CACHE:2431 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1074 ARCHIVED:77719 CACHE:2428 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1073 ARCHIVED:77674 CACHE:2420 FOLLOWERS:17 FOLLOWING:14

@falsifian@www.falsifian.org @bender@twtxt.net I pushed an alternative implementation to the fetch-context branch. This integrates the whole thing into mutt/jenny.

You will want to configure a new mutt hotkey, similar to the “reply” hotkey:

macro index,pager <esc>C "\
<enter-command> set my_pipe_decode=\$pipe_decode nopipe_decode<Enter>\
<pipe-message> jenny -c<Enter>\
<enter-command> set pipe_decode=\$my_pipe_decode; unset my_pipe_decode<Enter>" \
"Try to fetch context of current twt, like a missing root twt"

This pipes the mail to jenny -c. jenny will try to find the thread hash and the URL and then fetch it. (If there’s no URL or if the specific twt cannot be found in that particular feed, it could query a Yarn pod. That is not yet implemented, though.)

The whole thing looks like this:

https://movq.de/v/0d0e76a180/jenny.mp4

In other words, when there’s a missing root twt, you press a hotkey to fetch it, done.

I think I like this version better. 🤔

(This needs a lot of testing. 😆)

🧮 USERS:1 FEEDS:2 TWTS:1072 ARCHIVED:77642 CACHE:2395 FOLLOWERS:17 FOLLOWING:14

@prologic@twtxt.net Yes, fetching the twt by hash from some service could be a good alternative, in case the twt I have does not @-mention the source. (Besides yarnd, maybe this should be part of the registry API? I don’t see fetch-by-hash in the registry API docs.)

🧮 USERS:1 FEEDS:2 TWTS:1071 ARCHIVED:77616 CACHE:2388 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1070 ARCHIVED:77594 CACHE:2384 FOLLOWERS:17 FOLLOWING:14

@movq@www.uninformativ.de I don’t know if I’d want to discard the twts. I think what I’m looking for is a command “jenny -g https://host.org/twtxt.txt” to fetch just that one feed, even if it’s not in my follow list. I could wrap that in a shell script so that when I see a twt in reply to a feed I don’t follow, I can just tap a key and the feed will get added to my maildir. I guess the script would look for a mention at the start of a selected twt and call jenny -g on the feed.

🧮 USERS:1 FEEDS:2 TWTS:1069 ARCHIVED:77557 CACHE:2361 FOLLOWERS:17 FOLLOWING:14

@movq@www.uninformativ.de Is there a good way to get jenny to do a one-off fetch of a feed, for when you want to fill in missing parts of a thread? I just added @slashdot@feeds.twtxt.net to my private follow file just because @prologic@twtxt.net keeps responding to the feed :-P and I want to know what he’s commenting on even though I don’t want to see every new slashdot twt.

🧮 USERS:1 FEEDS:2 TWTS:1068 ARCHIVED:77550 CACHE:2366 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1067 ARCHIVED:77529 CACHE:2364 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1066 ARCHIVED:77504 CACHE:2358 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1065 ARCHIVED:77480 CACHE:2372 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1064 ARCHIVED:77457 CACHE:2354 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1063 ARCHIVED:77441 CACHE:2363 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1062 ARCHIVED:77432 CACHE:2367 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1061 ARCHIVED:77404 CACHE:2370 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1060 ARCHIVED:77372 CACHE:2407 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1059 ARCHIVED:77355 CACHE:2411 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1058 ARCHIVED:77343 CACHE:2415 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1057 ARCHIVED:77312 CACHE:2393 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1056 ARCHIVED:77295 CACHE:2392 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1055 ARCHIVED:77277 CACHE:2385 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1054 ARCHIVED:77272 CACHE:2420 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1053 ARCHIVED:77255 CACHE:2415 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1052 ARCHIVED:77238 CACHE:2443 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1051 ARCHIVED:77202 CACHE:2435 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1050 ARCHIVED:77116 CACHE:2393 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1049 ARCHIVED:77084 CACHE:2367 FOLLOWERS:17 FOLLOWING:14

Hmmm I’m a little concerned, as I’m seeing quite a few feeds I follow in an error state:

I’m not so concerned with the 15x context deadline exceeded but more concerned with:

aelaraji@aelaraji.com  Unfollow (6 twts, Last fetched 5m ago with error:
dead feed: 403 Forbidden
x4 times.)

And:

anth@a.9srv.net  Unfollow (1 twts, Last fetched 5m ago with error:
Get "http://a.9srv.net/tw.txt": dial tcp 144.202.19.161:80: connect: connection refused
x3733 times.)

Hmmm, maybe the stats are a bit off? 🤔

🧮 USERS:1 FEEDS:2 TWTS:1048 ARCHIVED:77055 CACHE:2368 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1047 ARCHIVED:77046 CACHE:2367 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1046 ARCHIVED:77041 CACHE:2387 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1045 ARCHIVED:77037 CACHE:2387 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1044 ARCHIVED:77033 CACHE:2384 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1043 ARCHIVED:77022 CACHE:2381 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1042 ARCHIVED:77001 CACHE:2369 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1041 ARCHIVED:76918 CACHE:2303 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1040 ARCHIVED:76910 CACHE:2313 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1039 ARCHIVED:76897 CACHE:2317 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1038 ARCHIVED:76887 CACHE:2330 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1037 ARCHIVED:76878 CACHE:2329 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1036 ARCHIVED:76865 CACHE:2323 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1035 ARCHIVED:76839 CACHE:2315 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1034 ARCHIVED:76828 CACHE:2318 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1033 ARCHIVED:76801 CACHE:2325 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1032 ARCHIVED:76781 CACHE:2307 FOLLOWERS:17 FOLLOWING:14

The delete twt is not working.

🧮 USERS:1 FEEDS:2 TWTS:1031 ARCHIVED:76765 CACHE:2327 FOLLOWERS:17 FOLLOWING:14

So updated. Seems to duplicate here in the ui. And what is this “Read More” on every twt now?

🧮 USERS:1 FEEDS:2 TWTS:1030 ARCHIVED:76734 CACHE:2313 FOLLOWERS:17 FOLLOWING:14

By the way, @xuu@txt.sour.is, it looks like you’re running an old, buggy version of yarnd, that duplicates twts in the feed on edit.

🧮 USERS:1 FEEDS:2 TWTS:1029 ARCHIVED:76716 CACHE:2297 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1028 ARCHIVED:76704 CACHE:2286 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1027 ARCHIVED:76691 CACHE:2276 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1026 ARCHIVED:76681 CACHE:2276 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1025 ARCHIVED:76659 CACHE:2295 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1024 ARCHIVED:76644 CACHE:2287 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1023 ARCHIVED:76626 CACHE:2279 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1022 ARCHIVED:76617 CACHE:2289 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1021 ARCHIVED:76613 CACHE:2295 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1020 ARCHIVED:76602 CACHE:2300 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1019 ARCHIVED:76587 CACHE:2319 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1018 ARCHIVED:76573 CACHE:2313 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1017 ARCHIVED:75609 CACHE:2312 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1016 ARCHIVED:75590 CACHE:2342 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1015 ARCHIVED:75561 CACHE:2359 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1014 ARCHIVED:75547 CACHE:2361 FOLLOWERS:17 FOLLOWING:14