@win0err@kolesnikov.se I guess it worked after @abucci@anthony.buc.ci nuked his pod’s cache? 🤔

@darch@neotxt.dk I meant about the original client, not an alternative frontend 😆

@abucci@anthony.buc.ci I don’t with a few minor exceptions I haven’t gotten rid of (yet)

@abucci@anthony.buc.ci Yes. That should 🤞 do it. No restarting a pod won’t delete the cache.

@abucci@anthony.buc.ci It does. But see above.

Btw… The only reason I can think of this not working as expected, is if the feed in fact hasn’t changed at all and so therefore the cached Metadata is unchanged and therefore it believes there is no refresh interval. In order to bust the cache here, the user/feed has to post a Twt or you can Refresh your Pod’s Cache.

@carsten@yarn.zn80.net Nice! 👌

@abucci@anthony.buc.ci Do you want this in the logs? Info maybe? Warn? 🤔

Hmmm nothing wrong with the code:

DEBU[0005] not refreshing feed https://kolesnikov.se/twtxt.txt with refresh=7200s (1h47m38.99999925s before next refresh)

Oh I know that person 👌 Lemme confirm something locally real quick 👌

@abucci@anthony.buc.ci Do you happen to have the feed uri handy? 🤔

@movq@www.uninformativ.de Come to think of it, it’s actually an appealing “options” thing to support anyway I think. It sure does make looking things up a lot easier. It makes no difference to us now, since we all follow each other and have webb established clients and following maps, but if we think another few years from now how things might evolve, new users might appreciate a more “straight forward” mechanisms/lookup and address/identity.

@darch@neotxt.dk If we want to make follow users and cross-pod mentioning easier for users, I would just drop the whole Twtxt feed URi entirely and just use webfinger period. Its far easier for non-technical people to reason about if we do that. Of course the actual Twtxt feed URL(s) are still there, just abstracted away from the users.

And this is true, I wouldn’t expect every Twtxt feed on ever web server to have a webfinger service. So we’d have to fallback anyway.

@movq@www.uninformativ.de I think the only thing this bus us is “shorter identities” with feed uris that can be looked up and validated, really.

@darch@neotxt.dk Hmmm 🤔

Cool idea though 😅

I kind of. have a problem with this:

Don’t share these addresses.
They contain an identifier that other people could use to send you spam and to control your newsletter subscriptions.

How are you suppose to do that when the same identifier is part of the Atom feed’s URI?! 🤦‍♂️ Hmmm 🤔

@movq@www.uninformativ.de Yes 👌

@abucci@anthony.buc.ci It is however an RFC: https://www.rfc-editor.org/rfc/rfc7033

The only noticeable thing you would see at all is all of a sudden (assuming you followed the old feed and new feed) you would see otherwise identical replies to some “root” that looks like its from two different identifies (feeds)

@abucci@anthony.buc.ci Actually it wouldn’t change any of the hashes at all. The old Twts from the previous feed’s URI would still remain in-tact. In the case of Yarn.social pods running yarnd, they are also archived, the search engine running at search.twtxt.net running yarns would also have indexed them already. Merging an old feed of yours from a different feed URI to a new one would have no impact whatsoever.

New Year, New Avatar 😅

@notvantablack@yarn.zn80.net Hey! 👋 Welcome to Yarn.social 🤗

@carsten@yarn.zn80.net Thank you! 🙇‍♂️

@movq@www.uninformativ.de There are two primary problems that the use of WebFinger can help solve (that I can think of):

• Conveniently sharing your Yarn.social / Twtxt “identity” with others, much like other competing ecosystems have done. e.g: prologic@twtxt.net (which can be looked up now with a webfinger client)
  
• Verifying @-mentions to be correct, potentially even rewriting them (yarnd does this anyway) to their proper @<url> form(s).

@rsdoiel@twtxt.net Not easily at this time, no. We would have to build an API endpoint so you can authenticate and grab an Atom version of your Timeline. I have to ask though… Why? 😅

@loopsaisei@twtxt.net

@prologic@twtxt.net Hey, I had no intent to complain or express frustration. Just really feel excited about what you ppl have created around twtxt and would like to engage to make things better.

This is awesome! 👌 We welcome any and all help we can get! 🙏 We especially need help in the UI/UX side of things, especially on the Mobile App 👌

@darch@neotxt.dk Why? 🤔 Clients like twtr and twete are just so much better 😅

@lyse@lyse.isobeef.org Well if you’re still up for it, I would be more than happy to write the client part itself, as a library that you could “just import”. I’d probably base it on the code in yarnd but heavily refactor it and write a shittone more tests 😅 Then eventually replace what yarnd uses too 👌

open to building a new client? As a Go library and Cli?

@lyse@lyse.isobeef.org You always seem to pick the nicest shot 😅

@lyse@lyse.isobeef.org I think @darch@neotxt.dk was probably interested in how this bad mention happened in the first place… So am I actually… Can you shed some light on how this happened? 🤔

This probably arrants some real-time conversation though. Are you up for a call this weekend/tomorrow? 🤔

@lyse@lyse.isobeef.org I’m thinking of generally the case of solving the of “bad data” when ti comes to @-mentions, typos, wrong urls and so on. In general if a client can validate an alias/mention (yes yarnd has a similar thing where we maintain a similar mapping per user and have lookup for that), then we can avoid this whole “bad data” mess in the first place. I’d also be interested to know what folks like @anth@a.9srv.net was thinking too when he mentioned the use of WebFinger. Anyway we’ll see how this pans out, yarnd (at least my pod) now has an experimental webfinger endpoint where you can do for example $ webfinger prologic@twtxt.net

Yeah that’s true I guess – Bit of a downside – But in theory you could probably do it with a static resource configuration 🤔

@abucci@anthony.buc.ci Yeah and I guess the nice thing is acct: could mean anything I guess

@abucci@anthony.buc.ci This is a little different though 😆

@darch@neotxt.dk Cool 👌

Haha no f**k Apple too 😆 If it weren’t the only desent acccessible OS for a vision impaired person I wouldn’t use it 🤣

I mean yeah sure, yarnd already does this today really, based on what’s in your “Followings” list on your account, which basically is a mapping of nick -> url of the feeds you follow. Really it could just be a simple list and we could drop the nick there too at some point (as again, we can just look them up and cache)

@darch@neotxt.dk Ahh you mean rewrite @-mentions into their fully formed Twtxt mention special URLs? 🤔

Use Preview to check this out on any frontpage of a pod or profile page 👌

@abucci@anthony.buc.ci You can, however that is not a lookup mechanism, more of a publishing standard. And yes all profile pages in yarnd implement this, as well as all feeds and the main frontpage discover feed too 👌

@darch@neotxt.dk I kind of agree that we can probably omit the nick part in mentions entirely. Since they can be looked up and cached, there’s no need for this. But we’ll have to spec this all up. First let’s see what @lyse@lyse.isobeef.org and @movq@www.uninformativ.de and others like @anth@a.9srv.net thing about finally formalising a standard way to lookup feed URI(s) and define a slightly more saner? @-mention syntax/usage pattern. I for one hate manually typing out (for example) @<darch https://neotxt.dk/user/darch/twtxt.txt> like this @darch@neotxt.dk 😅

@darch@neotxt.dk Yes for Macbooks with batteries, this makes a whole lot of sense 👌 For Mac(s), including Mac Studio, Mac mini and Mac Pro, this makes absolutely no sense 🤦‍♂️

I guess its usage in Twtxt clients could be something like this:

$ webfinger prologic@twtxt.net | jq -r '.links[] | select(.rel=="Self").href'
2023/01/06 02:32:40 Looking up WebFinger data for acct:prologic@twtxt.net
2023/01/06 02:32:40 GET https://twtxt.net/.well-known/webfinger?resource=acct%3Aprologic%40twtxt.net
https://twtxt.net/user/prologic/twtxt.txt

Where a lookup of user@domain would yield the Twtxt feed for that user+domain pair.

I guess in general though, it’s a pretty good lookup mechanism. I also wrote a command-line tool webfinger you can intall with go install go.mills.io/webfinger/cmd/webfinger@latest and use like this:

webfinger prologic@twtxt.net

@abucci@anthony.buc.ci Did you miss #33jt3fa and the subsequent twts in that yarn? 🤔

@abucci@anthony.buc.ci That’s kind of what I’m thinking too. it might be more trouble than it’s worth (not to mention that actually using and implementing Activity Pub just seems to be so fucking hard, like NP hard – Okay I’m slightly joking/exaggerating, but still 😅 – At least with the direction we’re going, we’ll likely just end up with new pods that by default are “invite-only” anyway.