Yesterday, I had a look at Unix domain sockets and how to obtain the caller information: https://lyse.isobeef.org/caller-information-via-unix-domain-sockets/

@prologic@twtxt.net yup. Funny enough, the first twtxt should have sufficed, as if there is no domain, there will be no feed (at that domain). The edit to add that the feed will not be available is redundant.

Hi @lyse@lyse.isobeef.org, I canceled the domain, so neotxt or my feed there are not coming back.

@eapl.me@eapl.me I wouldn’t call it natural, it is the way Bluesky decided to handle handles (not meaning to make a pun, or anything). There is no other way, but that.

The bottomline is, there are agreed upon “standards”, right? From example, on Yarnd you show as “eapl.me”, from “eapl.me”. A kind of weird redundancy because on twtxt, ever since I started using it, one will expect to see a “nick” (equivalent to a person’s first name), from “a domain” (like a surname).

There is nothing holding back someone from giving themselves the nick:

thisismyawesomenickforwhichiwillbeknownforeverandeveritsgreatisntit

But, do we really want that? 😅

hehe, just catching up on this thread! I’ve replied in another that using periods/dots sounds good to me as it’s usual in domains, but perhaps some agreement would be needed. For now I think any character is valid as long as it is not a space.
For example we are using this for PHP twtxt.php#L153

on timeline the mention looks OK. Is there an issue on Yarn?

It’s an interesting topic. For example on Bsky it’s natural to allow domains https://bsky.social/about/blog/4-28-2023-domain-handle-tutorial

Although TwiXter only allows (letters A-Z, numbers 0-9 and of underscores)
https://help.x.com/en/managing-your-account/x-username-rules

Zoom Outage Caused by Accidental ‘Shutting Down’ of the Zoom.us Domain
Comments ⌘ Read more

published: ‘Le Bureau’: a domain registrar cooperative https://copyleftculture.com/le-bureau.html

Public domain technical books published before 1964
Comments ⌘ Read more

Un petit test sur le domaine 0xe9.net

Most promoted and blocked domains on Kagi
Comments ⌘ Read more

working on my bookmarks tool, I found out that http(s)://domain.tls is not a valid resource, but http(s)://domain.tls/ is, as you can see here: https://stackoverflow.com/a/2581423

I suppose that internally the wget/curl or whatever client you are using is redirecting it?

@doesnmppsflt@doesnm.p.psf.lt this one is the safest feed to follow. Quark’s will cease to exist, as I am not renewing the domain. Bender’s will eventually fade away too, I am afraid. “No show, however good, can last forever.” :-)

@eapl.me@eapl.me Read flags are so simple, yet powerful in my opinion. I really don’t understand why this is not a thing in most twtxt clients. It’s completely natural in e-mail programs and feed readers, but it hasn’t made the jump over to this domain.

While I now have a somewhat working fix for it in yarnd (https://git.mills.io/yarnsocial/yarn/pulls/1232), I also have the feeling that I should fix literal formatting in lextwt as well. This also uncovered more bugs I believe: https://git.mills.io/yarnsocial/go-lextwt/pulls/28

But then there is also the question why the textarea is populated with @<url> in the first place rather than @<nick url> or yarnd’s own @nick@domain/@nick syntax. It indeed has to do something with whether I follow the mentioned feed or not.

Anyway, something to investigate for future Lyse or maybe @prologic@twtxt.net and/or @xuu@txt.sour.is. G’night!

Righto, must be some caching thing that’s going on, too. Now, with JS enabled and a feed that I follow, hitting “Reply” actually automatically enters @nick@domain in the textarea. Submitting it correctly writes “@in the feed. Let's dig…

@bender@twtxt.net @prologic@twtxt.net I can reproduce this locally, too. But it doesn’t matter if I follow the feed or not. With JS enabled, hitting “Reply” opens a textarea with @<url>. Submitting this writes @<domain url> instead of @<nick url> in the feed.

However, when I have JS disabled, “Reply” jumps to the top of the page, but the the textarea is at the bottom. So, after scrolling down, the textarea is not filled with anything. Which is expected I reckon. Entering @nick@domain or just @nick resolves to the correct @<nick url> in the feed.

@lyse@lyse.isobeef.org oh yeah i forgot to mention i changed the domain to pinktape lol! sorry about that! https://pinktape.girlonthemoon.xyz/

@lyse@lyse.isobeef.org Die meisten Hersteller von Internetradios (Sony, Denon, Marantz, …) binden einen externen Dienstleister (vTuner) fest(!) in ihre Geräte ein, damit die Nutzer sich durch eine große große Liste von weltweiten Internetradio-Stationen hören können.
Nun hat vTuner seit ca. 2020 sein Geschäftsmodell geändert. Man darf da nun für jedes Gerät (MAC-Adresse) bezahlen. Die Kosten steigen auch von $3 auf $7 pro Jahr. Die Hersteller zucken einfach mit den Schultern. Im schlimmsten Fall schaltet vTuner einfach die Domain ab und dann steht man da - wie bei mir: http://sagem.vtuner.com
Der XML-Parser von der alten Sagem-Huddel verlangt zeilenweise Einträge ohne Einzüge. Vielleicht standest Du mit Deinem Parser ja Pate!? 😉

@kat@yarn.girlonthemoon.xyz I approve! That’s how I learned HTML (version 4 at the time and XHTML shortly after) and making websites, too. Some of them are still made like this to this day. Hand-written HTML. Hardly any <div> and class nonsense. I can’t remember with which editor I started out with, but I upgraded to Webweaver (later renamed to Webcraft) quickly. Yeah, this were the times when there was just a single computer for the whole family.

Free hosting on Arcor, Freenet and I don’t know anymore how they were all called. Like this author, I uploaded everything via FTP. Oh dear, when was the last time I used that? And I had registered plenty of free .de.vu domains.

Being on Windows at the time, everything was ISO-8859-1 for me. No UTF-8, I don’t think I’ve heard about it back then.

Later, I wrote my own CMSes in PHP. Man, were they bad in retrospect. :-D Of course, MySQL databases were used as backends. I still exactly know the moment I read the first time about SQL injections. I tried it on my own CMS login and was shocked when I could just break in. The very next thing I did was to lock down everything with an .htaccess until I actually fixed my broken PHP code. Hahaha, good memories.

I swear by Atom or RSS feeds. Many of my sites offer them. I daily consume feeds, they’re just great.

Sounds about as complex as adding @nick@domain support by doing a webfinger lookup to get the URL.

Would anyone object to the feeds.twtxt.net service having auth soon™ ? 🤔 I’m tired of the garbage feeds that it has accumulated over tie (spammers) and I want to a) clean it up b) lock it down somewhat.

The idea would be that you’d login with your Yarn.social account on some pod you control/operate or share with a nice person 🤣 – For those unfamiliar, this is called IndieAuth or IndieLogin. ALL Yarn.social pods are in fact valid (have been for years now) IndieAuth Providers. So I can just ust that. This also technically means you could login with your own domain too (more on that later…)

@prologic@twtxt.net I say we should find a way to support mentions with only url, no nick, as per the original spec.

• For @<nick url> we already got support
  
• For @<nick> the posting client should expand it to @<nick url>, if not then the reading client should just render it as @nick with no link.
  
• For @<url> the sending client should try to expand it to @<nick url>, if not then the reading client should try to find or construct a nick base on:
  
  1. Look in twtxt.txt for a nick =
     
  2. Use (sub)domain from URL
     
  3. Use folder or file name from URL

I am letting this domain go at the end of this year. Another of my alter ego feeds will be gone then. Oh, the humanity! 😅

Let’s return to previous conversation: what if detect nick from url: pubnix.com/~nick/twtxt.txt is nick, domain.com/anick.txt is anick and etc

@prologic@twtxt.net If you’ve got the feed URL in yarnd’s cache, you can easily look up a missing nick. If you can’t find it, just show the URL (or maybe just the domain name to be halfway consistent with this @nick@domain thing that yarnd invented) and be done. It’s really that simple.

When yarnds peer with each other, the odds of actually having come across that feed URL in the past are higher than with traditional clients that only have their local set of subscribed feeds. One additional improvment would be to also look at all the mentions and see if somebody used a nick for that URL and go with that.

Yeah, yarnd currently renders some really weird shit when the mention contains just a URL, but I’d call that a bug for sure.

Personally, I do not like the @nick@domain syntax at all. It looks silly to my eyes. What might have also contributed is the fact of this mentions syntax gotten screwed up so many times by yarnd in the past. But that’s a totally different topic.

Wow, GtS keeps getting better! Re: https://docs.gotosocial.org/en/latest/admin/domain_permission_subscriptions/#fun-stuff-to-do-with-domain-permission-subscriptions

StackExchange/dnscontrol: Infrastructure as code for DNS! 👈👈 Now this looks might interesting… I might look into this for managing my own domains and DNS. I note that my current registrar isn’t on the list of supported registrars, oh well, I don’t like OnlyDomains™ much anyway. Anyone familiar with these regisrars?

• AWS Route 53
  
• CSC Global
  
• CentralNic Reseller (formerly RRPProxy)
  
• DNSOVERHTTPS
  
• Dzynadot
  
• easyname
  
• Gandi
  
• HEXONET
  
• hosting.de
  
• Internet.bs
  
• INWX
  
• Namecheap
  
• Name.com
  
• OpenSRS
  
• OVH
  
• Realtime Register

@emmanuel@wald.ovh Btw I already figured out why accessing your web server is slow:

$ host wald.ovh
wald.ovh has address 86.243.228.45
wald.ovh has address 90.19.202.229

wald.ovh has 2 IPv4 addresses, one of which is dead and doesn’t respond.. That’s why accessing your website is so slow as depending on client and browser behaviors one of two things may happen 1) a random IP is chosen and ½ the time the wrong one is picked or 2) both are tried in some random order and ½ the time its slow because the broken one is picked.

If you don’t know what 86.243.228.45 is, or it’s a dead backup server or something, I’d suggest you remove this from the domain record.

@prologic@twtxt.net No I’m not trying to standardize the domains themselves xD I was just hinting at filtering cases where nick is identical to a level of a domain; in order to show shorter format nicks within clients, i.e: @nick.domain.ltd or @nick.ltd instead of a @nick@nick.domain.ltd or @nick@nick.ltd. Just like what @sorenpeter@darch.dk already did with the nick = domain case. (unless I’m missing the point)

@sorenpeter@darch.dk Here are two more cases:

• nick = subdomain: https://aelaraji.com/timeline/profile?url=https://lyse.isobeef.org/twtxt.txt -> lyse.isobeef.org
  
• nick = second level domain: https://aelaraji.com/timeline/profile?url=https://aelaraji.com/twtxt.txt -> aelaraji.com

I’ve implemented Use only nick as handle if nick and domain is the same · sorenpeter/timeline@8c12444

See it live at:

• nick = domain: https://darch.dk/timeline/profile?url=https://eapl.me/tw.txt
  
• nick ≠ domain: https://darch.dk/timeline/profile?url=https://twtxt.net/user/prologic/twtxt.txt
  
• no nick, use domain: https://darch.dk/timeline/profile?url=https://akkartik.name/twtxt.txt
  

I’m not sure I like the leading @ thou…

What should the advantage be to nick = _compared to just not defining a nick and let the client use the domain as the handle?

What is not intuitive is that you put something in the nick field that is not to be taken literary. The special meaning of _ is only clean if you read the documentation, compared to having something in nick that makes sense in the current context of the twtxt.txt.

@doesnm@doesnm.p.psf.lt So the user should then set nick = _@domain.tld in the twtxt.txt?

It seems more intuitive and userfriendly to just use: nick = domain.tld and have then convention for clients to render the handle as @domain.tld instead of @domain.tld@domain.tld

For a feed with no nick defined (eg. https://akkartik.name/twtxt.txt) it will also be simpler and make more sense to just use the domain as the nick and render it as @domain.tld

Why not nostr way? https://github.com/nostr-protocol/nips/blob/master/05.md#showing-just-the-domain-as-an-identifier

Are we talking about profile view heading, heading of posts or inline mentions?
In yarnd I recall there is a setting for changing the heading of posts, but not for the two others as of yet.
I like the hover option for inline mentions. For the other places some like how yarnd does it in two line or “ nick (domain.tld) ” could also work.

and going back to a handle you could input in your client to look for the user/file, like @nick@domain.tls I think Webfinger is the way to go. It has enough information to know where to find that nick’s URL.

@prologic@twtxt.net does that webfinger fork made by darch work OK with yarn as it is now? (I’ve never used it, so I’m researching about it)
https://darch.dk/.well-known/webfinger/

I’m just having a similar issue with a podcast I just uploaded on Castopod (which supports ActivityPub).

My first thought was creating a subdomain with the name of the podcast mordiscos.eapl.me

Then I watched that the software allows many podcasts in the same domain, so I had to pick a handle:
https://mordiscos.eapl.me/@podcast

So now I have @podcast@mordiscos.eapl.me when this one is ‘more correct’ @mordiscos@podcast.eapl.me or it could even be @mordiscos.eapl.me
I wasn’t aware of all that when I setup Castopod (documentation might improve a lot, IMO)

My point here is that it’s something important to think from the start, otherwise is painful to change if it’s already being used like that.

my 2 cents here…
I agree on displaying a short @nick.

We could hover on the nick to see the full detail which could be @nick@domain.tls or the full URL
Also it could be a display option in Preferences in case your account starts showing many collisions.

The disambiguation for collisions is the .txt URL and the nick inside it, right ?

I don’t get why displaying nick@domain is preferred over just @nick in the first place. The twtxt world here is so small (and hopefully will always be) that duplicate nicks are just not an issue from my point of view. And even if there are several feeds with the same nicks, one probably does not follow both of them. Yes, there’s the birthday paradox, but I’d guess we have a slightly larger nickname space than days in a year.

@eapl.me@eapl.me A way to have a more bluesky’ish handles in twtxt could be to take inspiration from Bridgy Fed and say: If NICK = DOMAIN then only show @DOMAIN
So instead of @eapl.me@eapl.me it will just be @eapl.me

And it event seem that it will not break webfinger lookup: https://webfinger.net/lookup/?resource=%40darch.dk (at least not for how I’ve implemented webfinger on my sever for a single user;)

I like the cleaness and indiewebness of using just domains for handles/shorthands similar to blusky, but the situations with more users on the same domain and that people in the fediverse (threads too?) are already familiar with the syntax speaks for webfinger. And since we already got support for webfinger in both yarnd and timeline it makes sense to stick with it.

I think we could discuss on implementation details like URLs and Handles.

@nick@nick (Masto/Yarn style)
vs
@nick.eapl.me and @eapl.me (Bsky style)

I see, for example, that yarn shows my account as @eapl.me@eapl.me which looks ‘weird’ although it’s not wrong since my domain and my nick are the same. Honestly I like more the Bsky approach as in https://bsky.app/profile/eapl.me for @eapl.me, as when you look for https://eapl.me, it’s my home page.

Also, I didn’t get it completely if you are also proposing a URL standard using subdomains, like https://nick.domain.tls. I only want to point out that these are more difficult to handle from shared hostings, so I’d prefer to also allow https://domain.tls/nick/

after thinking and researching about it, yep, I agree that WebFinger is a good idea.

For example reading here: https://bsky.social/about/blog/4-28-2023-domain-handle-tutorial
I wasn’t considering some scenarios, like multiple accounts for a single domain (See ‘How can I set and manage multiple subdomain handles?’ in the link above)

@eapl.me@eapl.me why not https://domain.com/.well-known/twtxt/:domain/:user ?

the business card test is this can you write it on your business card and have someone you give it to be able to figure it out without added context?

• phone number: yes because everyone knows what a phone number is.
  
• email address: yes, everyone knows an email and their aol or prodigy will let them email.
  
• twitter/x/insta/pintrest handle: no, whats a twitter? do i need to sign up?
  
• domain name: yes its simple and you just type it in a browser right?
  
• twtxt url: kinda? its a bit long and is that a forward slash? or a backward slash?

since twtxt is based on text files, I think you can consider @domain.tld as an alias of http://domain.com/twtxt.txt (or https://domain.com/tw.txt, among other combinations in the wild).

Or perhaps you can use DNS TXT records?
Although I think that’s a bit more complicated for some environments and users, I’d go with looking for a default /tw*.txt

One benefit with bluesky is your username is also a website. And not a clunky URL with slashes and such. I wish twtxt adopted that. I have advocated for webfinger to for twtxt to let us do something like it with usernames. Nostr has something like it

By default the bsky.social urls all redirect to their feeds like: hmpxvt.bsky.social
Many custom urls will redirect to some kind of linktree or just their feed cwebonline.com or la.bonne.petite.sour.is or if you are a major outlet just to your web presence like https://theonion.com‬ or https://netflix.com

Its just good SEO practice

Do all nostr addresses take you to the person if typed into a browser? That is the secret sauce.
No having to go to some random page first. no accounts. no apps to install. just direct to the person.

According to internet it’s adshield and i dont think you should allow this domain: https://redlib.nadeko.net/r/uBlockOrigin/comments/188khmu/site_breaks_with_error_unless_ad_domain_is/

I was today years old when I learned that Firefox supports custom per-domain CSS. Is this new? I thought I had tried a while ago and it only worked globally. 🤔

@-moz-document domain(movq.de)
{
    div { border: 1px solid red; }
}

Either way, I love that I don’t need a plugin for that. 🥳

Mardi et mercredi prochains, une coupure de courant est prévue dans mon quartier. Les domaines si3t.ch et puffy.cafe seront donc inaccessibles le temps de l’intervention d’ENEDIS