# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 196219
# self = https://watcher.sour.is?offset=178456
# next = https://watcher.sour.is?offset=178556
# prev = https://watcher.sour.is?offset=178356
You are right: no advantage. Also your method can make backward compatible to feeds which doesn't implement metadata extension
@sorenpeter No I agree. I think if the feed doesn't hint at a nick, just default to displaying the bare domain. These sorts of things btw need to go into a Client recommendations / guidelines. If someone wants to start drafting up such I doc I will fully support this and help shape it 👌
@sorenpeter No I agree. I think if the feed doesn't hint at a nick, just default to displaying the bare domain. These sorts of things btw need to go into a Client recommendations / guidelines. If someone wants to start drafting up such I doc I will fully support this and help shape it 👌
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.
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.
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.
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.
[47°09′50″S, 126°43′39″W] Transfer aborted
@doesnm That can be done fairly easily I think/
@doesnm That can be done fairly easily I think/
No te quito el ojo
#catsoftwtxt
No te quito el ojo
#catsoftwtxt
No, i mean just _. If my nick = _ and my twtxt is located at https://doesnm.cc/twtxt.txt then just display me as doesnm.cc. Why it's not intuitive?=
@doesnm 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
@doesnm 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
@doesnm 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
@doesnm 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
@doesnm 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
@doesnm 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
@doesnm 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
@doesnm 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
[47°09′57″S, 126°43′39″W] Bad satellite signal -- switching to analog communication
[47°09′29″S, 126°43′56″W] Saalmi, retransmit, please
Se acerca la medianoche, vamos a ver que nos trae el niño dios jaja
@aelaraji I am sure it will run fine. I mean, mine is on a VPS, with 1GB RAM, 1vCPU, and shares it with Conduwit (Matrix), a few websites, Headscale, etc. 😂
@bender Le Me is _very_ tempted to spin up my own but not sure my pet computer(/server wannabe) and stone age bandwidth can withstand the Fedi-load 😅
@bender Le Me is _very_ tempted to spin up my own but not sure my pet computer(/server wannabe) and stone age bandwidth can withstand the Fedi-load 😅
@bender Le Me is _very_ tempted to spin up my own but not sure my pet computer(/server wannabe) and stone age bandwidth can withstand the Fedi-load 😅
Merry Xmas everyone! have a blessed and happy day! 🎉
Merry Xmas everyone! have a blessed and happy day! 🎉
Merry Xmas everyone! have a blessed and happy day! 🎉
Que divertido es esto, nunca usé twitter, y ahora uso twtxt \o/
🧮 USERS:1 FEEDS:2 TWTS:1194 ARCHIVED:82940 CACHE:2600 FOLLOWERS:17 FOLLOWING:14
Merry Christmas! Cute canine, as always! 🥰
Merry blessed Christmas to all gopherites.
Merry Christmas, everyone!
Merry 2024 Christmas 🎅 y'all 🥳 #Xmas24
Merry 2024 Christmas 🎅 y'all 🥳 #Xmas24
Happy Christmas Eve, or Festivus.
GoToSocial snapshot has gained "editing statuses" capabilities (and the ability to see the update trail as well). That was one of the things I wanted to most to be implemented. Actually, that sits at the top of my wish list. Next is push notifications.
[47°09′02″S, 126°43′42″W] --no signal--
@eapl.me that’s such a good plan! Staying at home, comfy, is all I wanted. But nooo! This brings true the saying in Spanish, “Una cosa piensa el borracho, y otra el bodeguero.” 😂
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.
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.
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.
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 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/
Oh no!
Wife and I agreed on hibernate until January, just visiting relatives but avoiding any kind of shopping. I tried buying something like 2 or 3 days ago and it's insane :o
Good luck! :)
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.
Grocery shopping in the day of Christmas Eve is nuts, and wife is dragging me through it. 😩
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 ?
[47°09′37″S, 126°43′23″W] Reading: 0.72000 PPM
Pinellas County Running: 8.10 miles, 00:09:35 average pace, 01:17:37 duration
needed to get out and get away from everything for a bit. turned into eight miles but was just what i needed.
#running
Pinellas County Running: 8.10 miles, 00:09:35 average pace, 01:17:37 duration
needed to get out and get away from everything for a bit. turned into eight miles but was just what i needed.
#running
Pinellas County Running: 8.10 miles, 00:09:35 average pace, 01:17:37 duration
needed to get out and get away from everything for a bit. turned into eight miles but was just what i needed.
#running
@lyse This is trie, I kind of agree here. In an ideal world, Yarn/Twtxt remains "purely" decentralised anyway so the change of that kind of collision in your (very small) network is highly unlikely right?
@lyse This is trie, I kind of agree here. In an ideal world, Yarn/Twtxt remains "purely" decentralised anyway so the change of that kind of collision in your (very small) network is highly unlikely 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.
[47°09′50″S, 126°43′01″W] --interrupted--
@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;)
@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;)
@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;)
@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;)
@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;)
@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;)
@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;)
@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;)
[47°09′50″S, 126°43′47″W] Transponder fixed
[47°09′04″S, 126°43′37″W] Transponder jammed
My daughter...
> Ahh this is too easy. Give me a human.
🤣 #AI #Sucks
My daughter...
> Ahh this is too easy. Give me a human.
🤣 #AI #Sucks
Hmmm upon further reading of the website and docs, I'm not actually sure how to use this? Hmmm 🤔
Hmmm upon further reading of the website and docs, I'm not actually sure how to use this? Hmmm 🤔
@bender No I haven't, but it looks pretty cool. The only question I have is, what if you don't want to hand out your email address? 🤔
@bender No I haven't, but it looks pretty cool. The only question I have is, what if you don't want to hand out your email address? 🤔
One thing I've learned over the many years now (_approaching a decade and a half now_) about self-hosting is two things; 1) There are many "assholes" on the open Internet that will either attack your stuff or are incompetent and write stupid shit™ that goes crazy on your stuff 2) You have to be careful about resources, especially memory and disk i/o. Especially disk i/o. this can kill your overall performance when you either have written software yourself or use someone else's that can do unconfined/uncontrolled disk i/o causing everything to grind to a halt and even fail. #self-hosted
One thing I've learned over the many years now (_approaching a decade and a half now_) about self-hosting is two things; 1) There are many "assholes" on the open Internet that will either attack your stuff or are incompetent and write stupid shit™ that goes crazy on your stuff 2) You have to be careful about resources, especially memory and disk i/o. Especially disk i/o. this can kill your overall performance when you either have written software yourself or use someone else's that can do unconfined/uncontrolled disk i/o causing everything to grind to a halt and even fail. #self-hosted
🧮 USERS:1 FEEDS:2 TWTS:1193 ARCHIVED:82927 CACHE:2592 FOLLOWERS:17 FOLLOWING:14
/https://baldo.cat/media/photos/IMG_3128.jpeg) #catsoftwtxt