@david@collantes.us Thanks I’ll fix.

@bender@twtxt.net I think mentions are fixed 🤣

This is nuts. Lemme eat dinner first (pizza on the way!) and I’ll fix this utter nonsense 🤣

@bender@twtxt.net I will figure this out soon™ and fix, it’s annoying the fuck out of me 🤣

Cool. That’s fixed! 🥳 I believe we’re now syncing to 6 peers again now. Hopefully with similar behavior as before 🤞

How’s that? Please refresh and see if that’s fixed? 🙏

@lyse@lyse.isobeef.org Thanks! Fixed the typos. The links will stay broken for a bit because my online man collection is busted. It’s on the list. :-/

Ordering issue is fixed 🥳

@bender@twtxt.net Let’s just optimize/fix those annoyances later on once I’ve finished pagination. Then I’ll merge this branch into main.

I believe the bug has been fixed 🥳

@david@collantes.us yeah @movq@www.uninformativ.de and I discovered its a bug in lextwt last night 😢 We’ll fix it as soon as @xuu@txt.sour.is can 🤣

@bender@twtxt.net @prologic@twtxt.net Shi% … my hotlinking problem is back! 😅 I’ll try and fix it this afternoon.

@kat@yarn.girlonthemoon.xyz I think it happens if you don’t follow them. Replies used to be broken if so, but not sure if @prologic@twtxt.net ever fixed that. I used not to follow him, so that he would see the broken mentions, and feel shame (he didn’t, he is shameless! LOL), but ever since the re-creation of my account I just decided to follow, so I don’t know if the issue is fixed or not.

I know mentioning @xuu@txt.sour.isdoesnm.p.psf.lt was broken too. Maybe still is? We’ll see.

@prologic@twtxt.net remember to fix this. Where did “xuu” come from? :-D

Can you confirm the fix temporarily in browser before I make the CSS change? I’m rubbish at CSS 🤣

@bender@twtxt.net Didn’t we fix this ages ago?! 🤦‍♂️

Fixed.

Confirmed. Fix inbound.

@bender@twtxt.net Please remind me to fix this after I’m done with this cachet branch and it’s merged 🤞

@bender@twtxt.net I know! 😂 Thankfully I think I fixed most problematic bugs 🤞

At least I’ve fixed many bugs with the new SQLiteCache 🤣

@lyse@lyse.isobeef.org Thanks for taking a look, and for pointing out the mixture of tabs and spaces.

I think I’ll leave reachability.c alone, since my intention there was to use an indent level of one tab, and the spaces are just there to line up a few extra things. I fixed reachability_with_stack.cc though.

@lyse@lyse.isobeef.org Luckily, yeah. Happens every now and then. It’s usually not even worth reporting, they often fix it in 30-90 minutes anyway.

@lyse@lyse.isobeef.org @bender@twtxt.net It already is a tiling window manager, but some windows can’t be tiled in a meaningful way. I admit that I’m mostly thinking about QEMU or Wine here: They run at a fixed size and can’t be tiled, but I still want to put them in “full screen” mode (i.e., hide anything else).

@lyse@lyse.isobeef.org There’s a reason it’s called “(n)curses”. 😏 The only advice I can give is to never fiddle with reassigning control sequences and $TERM variables. Leave $TERM at whatever value the terminal itself sets and use an appropriate terminfo file for it. If there are programs misbehaving, they probably blindly assume XTerm and should be fixed (or have XTerm as a hard requirement). If you try to fix this on your end, it’ll likely just break other programs. 🥴

trying to keep it simple but.. perhaps it can be extended to fix timestamp formats like using " " instead of "T"

@prologic@twtxt.net Don’t you dare fix it xD it’s not a bug, it’s a feature! xD

hmm any ideas how to fix this case when there is no nick and it on a shared tilde hosting? http://darch.dk/timeline/profile?url=https://tilde.club/~deepend/twtxt.txt

@movq@www.uninformativ.de interesting! So, what would the fix be, in this case, do you know? Aware of this, @prologic@twtxt.net?

@falsifian@www.falsifian.org “I don’t really mind if the twt gets edited before I even fetch it.”, right, that’s never the problem. Editing a twtxt before anyone fetches it isn’t even editing, right? :-P The problem we are trying to fix is the havoc is causes editing twtxts that have already been replied to, often ad nauseam. That’s the real problem.

@prologic@twtxt.net I have some ideas:

• Add smartypants rendering, just like Yarn has.
  
• Add the ability to create individual twtxts, each named after their hash.
  
• Fix the formatting of the help. :-P

It should be fixed now. Just needed some unusual quoting in my httpd.conf: https://mail-archive.com/misc@openbsd.org/msg169795.html

@movq@www.uninformativ.de I figured it will be something like this, yet, you were able to reply just fine, and I wasn’t. Looking at your twtxt.txt I see this line:

2024-09-16T17:37:14+00:00	(#o6dsrga) @<prologic https://twtxt.net/user/prologic/twtxt.txt>

@<quark https://ferengi.one/twtxt.txt> This is what I get. 🤔

Which is using the right hash. Mine, on the other hand, when I replied to the original, old style message (Message-Id: <o6dsrga>), looks like this:

2024-09-16T16:42:27+00:00	(#o) @<prologic https://twtxt.net/user/prologic/twtxt.txt> this was your first twtxt. Cool! :-P

What did you do to make yours work? I simply went to the oldest @prologic@twtxt.net’s entry on my Maildir, and replied to it (jenny set the reply-to hash to #o, even though the Message-Id is o6dsrga). Since jenny can’t fetch archived twtxts, how could I go to re-fetch everything? And, most importantly, would re-fetching fix the Message-Id:?

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

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

@prologic@twtxt.net This does not seem to fix the problem for me, or I’ve done something wrong. I did the following:

1. Pull the latest version from git (I have commit 7ad848, same as on twtxt.net I believe).
   
2. make build and make install
   
3. Restart yarnd
   
4. Refresh cache in Poderator Settings
   

Yet I still see these bogus /external things on my pod when I hit URLs like the one I sent you recently. When I hit such a URL with curl I think it’s giving an error? But in a web browser, the (buggy) response is the same as it was before I updated.

So, this problem is not fixed for me.

@prologic@twtxt.net Aha, now it gives an error. OK I’m updating to this to see if it fixes the issue on my pod! Thank you.

@aelaraji@aelaraji.com didn’t know there was a place to fix them; in here we toss them. Wish it was cheap to ship stuff. I have a couple of decent monitors in the garage that will soon take a trip to the curve…

@prologic@twtxt.net Ah nice, thank you! Do you think this fix is ready for me to test it or do you think I should wait til you poke at it?

@prologic@twtxt.net sounds fair. Let’s see how it works for @abucci@anthony.buc.ci. Speedy fix, that’s awesome! :-)

There is a bug in yarnd that’s been around for awhile and is still present in the current version I’m running that lets a person hit a constructed URL like

YOUR_POD/external?nick=lovetocode999&uri=https://socialmphl.com/story19510368/doujin

and see a legitimate-looking page on YOUR_POD, with an HTTP code 200 (success). From that fake page you can even follow an external feed. Try it yourself, replacing “YOUR_POD” with the URL of any yarnd pod you know. Try following the feed.

I think URLs like this should return errors. They should not render HTML, nor produce legitimate-looking pages. This mechanism is ripe for DDoS attacks. My pod gets roughly 70,000 hits per day to URLs like this. Many are porn or other types of content I do not want. At this point, if it’s not fixed soon I am going to have to shut down my pod. @prologic@twtxt.net please have a look.

(@anth@a.9srv.net’s feed almost never works, but I keep it because they told me they want to fix their server some time.)

[fixed]

@movq@www.uninformativ.de my bad man. I left off a return in the formatter func. I have a PR to fix waiting on @prologic@twtxt.net

@stigatle@yarn.stigatle.no Sweet, thank you! I’ve been shooting myself in the foot over here and want to make sure the situation is getting fixed!

@prologic@twtxt.net I’m still getting this crap:

abucci@buc:~/yarnd/yarn$ ls -lh /tmp/yarnd-avatar-*
-rw------- 1 abucci abucci 863M Jul 25 14:19 /tmp/yarnd-avatar-1594499680
-rw------- 1 abucci abucci 7.8G Jul 25 14:19 /tmp/yarnd-avatar-2144295337
-rw------- 1 abucci abucci 9.8G Jul 25 14:19 /tmp/yarnd-avatar-2334738193
-rw------- 1 abucci abucci  10G Jul 25 14:14 /tmp/yarnd-avatar-2494107777
-rw------- 1 abucci abucci 9.5G Jul 25 13:59 /tmp/yarnd-avatar-2619243454
-rw------- 1 abucci abucci  11G Jul 25 14:04 /tmp/yarnd-avatar-2922187513
-rw------- 1 abucci abucci 7.5G Jul 25 14:14 /tmp/yarnd-avatar-349775570
-rw------- 1 abucci abucci  10G Jul 25 14:09 /tmp/yarnd-avatar-3640724243
-rw------- 1 abucci abucci 901M Jul 25 14:19 /tmp/yarnd-avatar-3921595598
-rw------- 1 abucci abucci 9.5G Jul 25 13:59 /tmp/yarnd-avatar-609094539
-rw------- 1 abucci abucci 9.3G Jul 25 14:04 /tmp/yarnd-avatar-755173392
-rw------- 1 abucci abucci 7.9G Jul 25 14:09 /tmp/yarnd-avatar-984061000

Something like 100 Gbytes of this junk has accumulated since I updated and re-started the server. I’m now running the latest version of yarnd, so the update did not fix the problem. Something else is going wrong.

How are temporary files growing to 10 Gbytes in size? The name of the file is “yarn-avatar”, but why would avatars be so large?

@prologic@twtxt.net Fix works!

I fixed it by adding (?<!\S) to the regex filter. But what is going on with the ?nick=dbucklin anyhow?

@Prologic@twtxt.net can you pleas fix this line in your twtxt.txt:
# follow = dbucklin@www.davebucklin.com https://www.davebucklin.com/twtxt.txt?nick=dbucklin

It is cause this weird effect on my timeline, where you are now called dbucklin
http://darch.dk/timeline/?profile=https://twtxt.net/user/prologic/twtxt.txt

The wording can be more subtle like “This feed have not seen much activity within the last year” and maybe adding a UI like I did in timeline showing time ago for all feeds

Image

I agree that it good to clean up the Mastodon re-feeds, but it should also be okay for anyone to spin up a twtxt.txt just for syndicating they stuff from blog or what ever.

The “not receiving replies” could partly be fixed by implementing a working webmentions for twtxt.txt