@quark@ferengi.one wow everybody loves @prologic@twtxt.net

@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.

@movq@www.uninformativ.de good idea, considering it might occasionally not work at all (because of edited twtxts).

@dbucklin@www.davebucklin.com very nice, thank you for sharing! I like that kind of retailers too, so those are on my list now. 🙂

@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?

@prologic@twtxt.net I guess I thought they were search engines. Anyway, the registry API looks like a decent one for searching for tweets. Could/should yarn.social pods implement the same API?

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 What’s the difference between search.twtxt.net and the /api/plain/tweets endpoint of a registry? In my mind, a registry is a twtxt search engine. Or are registries not supposed to do their own crawling to discover new feeds?

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

@abucci@anthony.buc.ci OMFG! Dear jebus, look at the size of that! :-/ It is just a matter of time until one of those randomly falls on any of us. Just incredible!

For following notifications I would say use webmetion refering to the the line in your twtxt.txt as per: https://darch.dk/mentions-twtxt
Or send them an email, so it would be an idea to add a # contact = mailto:me@domain.net to ones twtxt.txt

@movq@www.uninformativ.de Thanks! Looking forward to trying it out. Sorry for the silence; I have become unexpectedly busy so no time for twtxt these past few days.

@quark@ferengi.one Check out this thread if you haven’t already: https://mastodon.social/@sundogplanets/112464533481477428

I think we already know It’s likely to be a disaster.

@movq@www.uninformativ.de LOL, well, great things come out of that worry, I can tell that much. Keep being you! :-)

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

@mckinley@twtxt.net agevault uses age, allegedly very secure (aiming to replace pgp/gpg). Comparing it with gocryptfs, from the user perspective, agevault seems simpler, though CLI exclusive. As the repository states, “Like age, it features no config options, allowing for a straightforward secure flow”. It would also run in all major OS platforms out of the box.

But agevault is also very new. Though age has been around for a while now, I don’t see an “audited” link (neither on agevault, nor age).

@abucci@anthony.buc.ci their main question is worrisome:

“The main question is, does it disappear during this re-entry?” says Löhle. “Is everything evaporating, or are there pieces that eventually impact on the ground?”

He expects some parts, such as the satellite’s fuel tanks, to survive. “You could learn from the re-entry that if you build a fuel tank differently, it can break up,” he says.

Archived article at: https://archive.ph/WdUvx

@aelaraji@aelaraji.com so lovely, ain’t it? A simple keystroke, and your “mystery” is solved. :-)

@New_scientist@feeds.twtxt.net It’s great that US regulators have approved launching 40,000 satellites with a 5-year lifespan before we had this kind of information about what’s likely to happen when they start falling out of orbit at a rate of several per hour.

@aelaraji@aelaraji.com hehehehe. Enjoy, but careful with sugary stuff! :-)

@prologic@twtxt.net what made you make such “financially sound” recommendation? Have you switched jobs, and are now a Financial Advisor? :-P

@movq@www.uninformativ.de wow! We are “lucky” today, only 27°C here, 87% humidity, overcast, and raining sporadically. Thanks to the rain our temperatures aren’t high, but muggy nevertheless. I am ready for our winter too, you know, that whole week. LOL.

@prologic@twtxt.net My pod, which is running the same commit you are, does not return an error like that. It returns the same HTML it always has. Try it. I nuked my cache before restarting.

Edit: Oh wait, the plot thickens. I do get an error if I use curl or if I use a web browser that isn’t logged in. That’s good!

@movq@www.uninformativ.de pretty cool! Switched, and pulled. Nice update on README!

@falsifian@www.falsifian.org have you tried jenny’s fetch-context branch? It works great!

@bender@twtxt.net yup, this works well. I needed those extra settings.

@movq@www.uninformativ.de I think I have got it, but need to test upon receiving further posts. I added:

set uncollapse_new     = yes  # open threads when new mail
set uncollapse_jump    = yes  # jump to unread message when uncollapse
set collapse_unread    = no   # don't collapse threads with unread mails

Let’s see how it goes.

Maybe the @yarn_police@twtxt.net can take this case, and shed some light.

@bender@twtxt.net, cool, so I can join the threads, but your edit to the original will never show at my end. Will have @bender@twtxt.net show the screenshot.

@bender@twtxt.net, let’s break it!

@prologic@twtxt.net I’m not sure what this update does, but

https://twtxt.net/external?uri=https://google.com&nick=lovetocode999

still exhibits the same problem, on your pod and on mine, after the latest update.

@prologic@twtxt.net OK, I just updated to commit 77d527, which looks to be the same one you’re running right now. I forgot to blow away my cache before restarting, so I just deleted the cache file and restarted.

Had to disable support functions because I’ve received three spammy support emails today. Thanks for that feature @prologic@twtxt.net

@bender@twtxt.net Hey, want to go in halfsies on one?

@bender@twtxt.net Oh look at that, the same problem is still happening on twtxt.net too. I tested a different link but that one gave an error. Maybe that means my pod isn’t behaving different from twtxt.net after all.

@prologic@twtxt.net I deleted a file named cache in my yarn data and restarted. Problem persists.

@prologic@twtxt.net “Refresh cache in Poderator Settings”

Is there some other way to do that?

@prologic@twtxt.net What? I compiled, updated, and restarted. If you check what my pod reports, it gives that 7a… SHA. I don’t know what that other screenshot is showing but it seems to be out of date. That was the SHA I was running before this update.

@prologic@twtxt.net Here’s a log entry:

Aug 27 15:59:43 buc yarnd[1200580]: [yarnd] 2024/08/27 15:59:43 (IP_REDACTED) "GET /external?nick=lovetocode999&uri=https://URL_REDACTED HTTP/1.1" 200 35442 14.554763ms

HTTP 200 status, not 404.

@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.

@prologic@twtxt.net I believe you are not seeing the problem I am describing.

Hit this URL in your web browser:

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

That’s your pod. I assume you don’t have a user named lovetocode999 on your pod. Yet that URL returns HTTP status 200, and generates HTML, complete with a link to https://socialmphl.com/story19510368/doujin, which is not a twtxt feed (that’s where the twtxt.txt link goes if you click it). That link could be to anything, including porn, criminal stuff, etc, and it will appear to be coming from your twtxt.net domain.

What I am saying is that this is a bug. If there is no user lovetocode999 on the pod, hitting this URL should not return HTTP 200 status, and it should definitely not be generating valid HTML with links in it.

Edit: Oops, I misunderstood the purpose of this /external endpoint. Still, since the uri is not a yarn pod, let alone one with a user named lovetocode999 on it, I stand by the belief that URLs like this should be be generating valid HTML with links to unknown sites. Shouldn’t it be possible to construct a valid target URL from the nick and uri instead of using the pod’s /external endpoint?

@prologic@twtxt.net @bender@twtxt.net I partially agree with bender on this one I think. The way this person is abusing the /external endpoint on my pod seems to be to generate legitimate-looking HTML content for external sites, using a username that does not exist on my pod. One “semantically correct” thing to do would be to error out if that username does not exist on the pod. It’s not unlike having a mail server configured as an open relay at this point.

It would also be very helpful to give the pod administrator control over what’s being fetched this way. I don’t want people using my pod to redirect porn sites or whatever. If I could have something as simple as the ability to blacklist URLs that’d already help.

@lyse@lyse.isobeef.org Interesting. The yarnd --help currently says (for me):

  -R, --open-registrations            whether or not to have open user registgration

meaning it doesn’t give the default setting or warn you that you need to use -R=false and not -R false. It also leaves unclear whether --open-registrations false would work or if you need to do --open-registrations=false. It’s also unclear whether the setting change in the user interface is overridden by the command line arguments, overrides the command line arguments, is persisted across restarts.

Maybe all this is worth posting an issue for additional documentation on the git repo if there isn’t one already.

“registgration” is misspelled that way in the help by the way.

@lyse@lyse.isobeef.org in Australia, take everything you have learned, and do the opposite. After all, it is the land down under! :-D

@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…

@lyse@lyse.isobeef.org ugh, how come didn’t this occurred to me…! Oh well, I am good now, but noted. Thanks!

@prologic@twtxt.net salt’em to keep them viable longer. Salt’em! :-D