🧮 USERS:1 FEEDS:2 TWTS:1114 ARCHIVED:79694 CACHE:2581 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1113 ARCHIVED:79690 CACHE:2578 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1112 ARCHIVED:79684 CACHE:2598 FOLLOWERS:17 FOLLOWING:14

Maybe i should sleep more? Noticed about mistake in my follow entry for prologic. Already fixed

🧮 USERS:1 FEEDS:2 TWTS:1111 ARCHIVED:79666 CACHE:2610 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1110 ARCHIVED:79632 CACHE:2622 FOLLOWERS:17 FOLLOWING:14

RISC-V-Based KVM Solution in PCIe Form Factor with Low/High Profile Compatibility
The NanoKVM-PCIe is a recent solution from Sipeed, designed to simplify remote management of ATX PC cases and 2U servers. Built on the RISC-V architecture, it offers low power consumption and easy installation, with compatibility for both low-profile and high-profile PCIe brackets. This product follows the recent release of the Lichee NanoKVM Cube, an IP-KVM […] ⌘ Read more

🧮 USERS:1 FEEDS:2 TWTS:1109 ARCHIVED:79618 CACHE:2654 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1108 ARCHIVED:79604 CACHE:2650 FOLLOWERS:17 FOLLOWING:14

Are EVs at risk of being hacked? And will Chinese EVs be banned?
The US has banned Chinese vehicle technology from its roads and some say Australia should follow suit. ⌘ Read more

It has twts cache which used if timeline is set to jew. Maybe i.should fork twet to make wishes like newlines (i see two squares), showing conversations, showing twts if not found in cache and parsing medata to configure url, nick and followers (currenly it duplicated in config and twtxt file)

🧮 USERS:1 FEEDS:2 TWTS:1107 ARCHIVED:79577 CACHE:2662 FOLLOWERS:17 FOLLOWING:14

@prologic@twtxt.net Done. Also, I went ahead and made two changes: changed hexadecimal to base64 for hashes (wasn’t sure if anyone objected), and changed “MUST follow the chain” to “SHOULD follow the chain.

🧮 USERS:1 FEEDS:2 TWTS:1106 ARCHIVED:79449 CACHE:2645 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1105 ARCHIVED:79381 CACHE:2634 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1104 ARCHIVED:79360 CACHE:2633 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1103 ARCHIVED:79345 CACHE:2623 FOLLOWERS:17 FOLLOWING:14

Some more arguments for a local-based treading model over a content-based one:

1. The format: (#<DATE URL>) or (@<DATE URL>) both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash) and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.

2. Having something like (#<DATE URL>) will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash. This will also make it possible to make 3th part twt-mentions services.

3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don’t follow.

🧮 USERS:1 FEEDS:2 TWTS:1102 ARCHIVED:79309 CACHE:2611 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1101 ARCHIVED:79243 CACHE:2591 FOLLOWERS:17 FOLLOWING:14

@lyse@lyse.isobeef.org I’d suggest making the whole content-type thing a SHOULD, to accommodate people just using some hosting service they don’t have much control over. (The same situation could make detecting followers hard, but IMO “please email me if you follow me” is still legit twtxt, even if inconvenient.)

@prologic@twtxt.net Thanks for writing that up!

I hope it can remain a living document (or sequence of draft revisions) for a good long time while we figure out how this stuff works in practice.

I am not sure how I feel about all this being done at once, vs. letting conventions arise.

For example, even today I could reply to twt abc1234 with “(#abc1234) Edit: …” and I think all you humans would understand it as an edit to (#abc1234). Maybe eventually it would become a common enough convention that clients would start to support it explicitly.

Similarly we could just start using 11-digit hashes. We should iron out whether it’s sha256 or whatever but there’s no need get all the other stuff right at the same time.

I have similar thoughts about how some users could try out location-based replies in a backward-compatible way (append the replyto: stuff after the legacy (#hash) style).

However I recognize that I’m not the one implementing this stuff, and it’s less work to just have everything determined up front.

Misc comments (I haven’t read the whole thing):

• Did you mean to make hashes hexadecimal? You lose 11 bits that way compared to base32. I’d suggest gaining 11 bits with base64 instead.

• “Clients MUST preserve the original hash” — do you mean they MUST preserve the original twt?

• Thanks for phrasing the bit about deletions so neutrally.

• I don’t like the MUST in “Clients MUST follow the chain of reply-to references…”. If someone writes a client as a 40-line shell script that requires the user to piece together the threading themselves, IMO we shouldn’t declare the client non-conforming just because they didn’t get to all the bells and whistles.

• Similarly I don’t like the MUST for user agents. For one thing, you might want to fetch a feed without revealing your identty. Also, it raises the bar for a minimal implementation (I’m again thinking again of the 40-line shell script).

• For “who follows” lists: why must the long, random tokens be only valid for a limited time? Do you have a scenario in mind where they could leak?

• Why can’t feeds be served over HTTP/1.0? Again, thinking about simple software. I recently tried implementing HTTP/1.1 and it wasn’t too bad, but 1.0 would have been slightly simpler.

• Why get into the nitty-gritty about caching headers? This seems like generic advice for HTTP servers and clients.

• I’m a little sad about other protocols being not recommended.

• I don’t know how I feel about including markdown. I don’t mind too much that yarn users emit twts full of markdown, but I’m more of a plain text kind of person. Also it adds to the length. I wonder if putting a separate document would make more sense; that would also help with the length.

🧮 USERS:1 FEEDS:2 TWTS:1100 ARCHIVED:79197 CACHE:2589 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1099 ARCHIVED:79147 CACHE:2577 FOLLOWERS:17 FOLLOWING:14

@movq@www.uninformativ.de I don’t think it has to be like that. Just make sure the new version of the twt is always appended to your current feed, and have some convention for indicating it’s an edit and which twt it supersedes. Keep the original twt as-is (or delete it if you don’t want new followers to see it); doesn’t matter if it’s archived because you aren’t changing that copy.

🧮 USERS:1 FEEDS:2 TWTS:1098 ARCHIVED:79066 CACHE:2530 FOLLOWERS:17 FOLLOWING:14

I wrote some code to try out non-hash reply subjects formatted as (replyto ), while keeping the ability to use the existing hash style.

I don’t think we need to decide all at once. If clients add support for a new method then people can use it if they like. The downside of course is that this costs developer time, so I decided to invest a few hours of my own time into a proof of concept.

With apologies to @movq@www.uninformativ.de for corrupting jenny’s beautiful code. I don’t write this expecting you to incorporate the patch, because it does complicate things and might not be a direction you want to go in. But if you like any part of this approach feel free to use bits of it; I release the patch under jenny’s current LICENCE.

Supporting both kinds of reply in jenny was complicated because each email can only have one Message-Id, and because it’s possible the target twt will not be seen until after the twt referencing it. The following patch uses an sqlite database to keep track of known (url, timestamp) pairs, as well as a separate table of (url, timestamp) pairs that haven’t been seen yet but are wanted. When one of those “wanted” twts is finally seen, the mail file gets rewritten to include the appropriate In-Reply-To header.

Patch based on jenny commit 73a5ea81.

https://www.falsifian.org/a/oDtr/patch0.txt

Not implemented:

• Composing twts using the (replyto …) format.
  
• Probably other important things I’m forgetting.

🧮 USERS:1 FEEDS:2 TWTS:1097 ARCHIVED:79000 CACHE:2495 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1096 ARCHIVED:78954 CACHE:2471 FOLLOWERS:17 FOLLOWING:14

@sorenpeter@darch.dk I like this idea. Just for fun, I’m using a variant in this twt. (Also because I’m curious how it non-hash subjects appear in jenny and yarn.)

URLs can contain commas so I suggest a different character to separate the url from the date. Is this twt I’ve used space (also after “replyto”, for symmetry).

I think this solves:

• Changing feed identities: although @mckinley@twtxt.net points out URLs can change, I think this syntax should be okay as long as the feed at that URL can be fetched, and as long as the current canonical URL for the feed lists this one as an alternate.
  
• editing, if you don’t care about message integrity
  
• finding the root of a thread, if you’re not following the author
  

An optional hash could be added if message integrity is desired. (E.g. if you don’t trust the feed author not to make a misleading edit.) Other recent suggestions about how to deal with edits and hashes might be applicable then.

People publishing multiple twts per second should include sub-second precision in their timestamps. As you suggested, the timestamp could just be copied verbatim.

🧮 USERS:1 FEEDS:2 TWTS:1095 ARCHIVED:78843 CACHE:2434 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1094 ARCHIVED:78808 CACHE:2451 FOLLOWERS:17 FOLLOWING:14

@mckinley@twtxt.net Thanks for the feedback.

1. Yeah I agrees that nick sound not be part of syntax. Any valid URL to a twtxt.txt-file should be enough and is more clear, so it is not confused with a email (one of the the issues with webfinger and fedivese handles)
   
2. I think any valid URL would work, since we are not bound to look for exact matches. Accepting both http and https as well as a gemni and gophe could all work as long as the path to the twtxt.txt is the same.
   
3. My idea is that you quote the timestamp as it is in the original twtxt.txt that you are referring to, so you can do it by simply copy/pasting. Also what are the change that the same human will make two different posts within the same second?!
   

Regarding the whole cryptographic keys for identity, to me it seems like an unnecessary layer of complexity. If you move to a new house or city you tell people that you moved - you can do the same in a twtxt.txt. Just post something like “I move to this new URL, please follow me there!” I did that with my feeds at least twice, and you guys still seem to read my posts:)

🧮 USERS:1 FEEDS:2 TWTS:1093 ARCHIVED:78768 CACHE:2438 FOLLOWERS:17 FOLLOWING:14

@mckinley@twtxt.net

HTTPS is supposed to do [verification] anyway.

TLS provides verification that nobody is tampering with or snooping on your connection to a server. It doesn’t, for example, verify that a file downloaded from server A is from the same entity as the one from server B.

I was confused by this response for a while, but now I think I understand what you’re getting at. You are pointing out that with signed feeds, I can verify the authenticity of a feed without accessing the original server, whereas with HTTPS I can’t verify a feed unless I download it myself from the origin server. Is that right?

I.e. if the HTTPS origin server is online and I don’t mind taking the time and bandwidth to contact it, then perhaps signed feeds offer no advantage, but if the origin server might not be online, or I want to download a big archive of lots of feeds at once without contacting each server individually, then I need signed feeds.

feed locations [being] URLs gives some flexibility

It does give flexibility, but perhaps we should have made them URIs instead for even more flexibility. Then, you could use a tag URI, urn:uuid:*, or a regular old URL if you wanted to. The spec seems to indicate that the url tag should be a working URL that clients can use to find a copy of the feed, optionally at multiple locations. I’m not very familiar with IP{F,N}S but if it ensures you own an identifier forever and that identifier points to a current copy of your feed, it could be a great way to fix it on an individual basis without breaking any specs :)

I’m also not very familiar with IPFS or IPNS.

I haven’t been following the other twts about signatures carefully. I just hope whatever you smart people come up with will be backwards-compatible so it still works if I’m too lazy to change how I publish my feed :-)

🧮 USERS:1 FEEDS:2 TWTS:1092 ARCHIVED:78761 CACHE:2445 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1091 ARCHIVED:78750 CACHE:2482 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1090 ARCHIVED:78738 CACHE:2498 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1089 ARCHIVED:78724 CACHE:2505 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1088 ARCHIVED:78704 CACHE:2506 FOLLOWERS:17 FOLLOWING:14

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

MNT Pocket Reform: Linux-Powered Mini Laptop with Rockchip RK3588 or Amlogic A311D CPU Modules
The MNT Pocket Reform is now officially available for purchase, following the successful delivery of crowdfunded units via Crowd Supply. This 7″ modular mini laptop offers a range of customization options, making it a suitable option for open-source enthusiasts and developers. Users can select from multiple CPU modules, including the A311D (Banana Pi) and t … ⌘ Read more

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

🧮 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

@bender@twtxt.net So far I’ve been following feeds fairly liberally. I’ll check to see if we have anything in common and lean toward following, just because this is new to me and it feels like a small community. But I’m still figuring out what I want. Later I’ll probably either trim my follower list or come up with some way to prioritize the feeds I’m more interested in.

@movq@www.uninformativ.de ha! Here are my top 10:

24056 "prologic"
5103 "lyse"
3932 "movq"
1984 "abucci"
1876 "adi"
1633 "fastidious"
1551 "jlj"
1455 "mckinley"
1413 "offgridliving
1280 "eaplmx"

Some of those I no longer follow, or do not exist, but their wisdom remains. LOL.

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 :-)

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