# 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 196278
# self = https://watcher.sour.is?offset=171725
# next = https://watcher.sour.is?offset=171825
# prev = https://watcher.sour.is?offset=171625
prologic
twtxt.net
View Thread
My Position on the last few weeks of Twtxt spec discussions:

- We increase the Hash length from 7 to 11.
- We formalise the Update Commands extension.
- We amend the Twt Hash and Metadata extension to state:

> Feed authors that wish to change the location of their feed (_once Twts have been published_) must append a new # url = comment to their feed to indicate the new location and thus change the "Hashing URI" used for Twts from _that_ point onward.

This has implications of the "order" of a feed, and we should either do one of two things, either:

- Mandate that feeds are append-only.
- Or amend the Metadata spec with a new field that denotes the order of the feed so clients can make sense of "inline" comments in the feed. -- This would also imply that the default order is (_of course_) append-only. Suggestion: # direction = [append|prepend]
prologic
twtxt.net
View Thread
My Position on the last few weeks of Twtxt spec discussions:

- We increase the Hash length from 7 to 11.
- We formalise the Update Commands extension.
- We amend the Twt Hash and Metadata extension to state:

> Feed authors that wish to change the location of their feed (_once Twts have been published_) must append a new # url = comment to their feed to indicate the new location and thus change the "Hashing URI" used for Twts from _that_ point onward.

This has implications of the "order" of a feed, and we should either do one of two things, either:

- Mandate that feeds are append-only.
- Or amend the Metadata spec with a new field that denotes the order of the feed so clients can make sense of "inline" comments in the feed. -- This would also imply that the default order is (_of course_) append-only. Suggestion: # direction = [append|prepend]
bender
twtxt.net
View Thread
The three things we briefly talk about tonight (your morning), so that I don’t forget:

1. Add the ability to allow feed address changes.
2. Increase hash from 7 to 11, and/or change the hashing algorithm to something else, better.
3. Implement movq (I simply can’t mention while on mobile) second option (the one you like, which maintains content addressing).
prologic
twtxt.net
View Thread
I finally decided to do a few experiments with yarnd to see how many things would break and how many assumptions there are around the idea of "Content Addressing"; here's where I'm at so far:

- What breaks

Basically I'm at a point where spending time on this is going to provide very little value, there are assumptions made in the lextwt parser, assumptions made in yarnd, assumptions in the way storage is done and the way threading works and things are looked up. There are far reaching implications to changing the way Twts are identified here to be "location addressed" that I'm quite worried about the amount of effort would be required to change yarnd here.

prologic
twtxt.net
View Thread
I finally decided to do a few experiments with yarnd to see how many things would break and how many assumptions there are around the idea of "Content Addressing"; here's where I'm at so far:

- What breaks

Basically I'm at a point where spending time on this is going to provide very little value, there are assumptions made in the lextwt parser, assumptions made in yarnd, assumptions in the way storage is done and the way threading works and things are looked up. There are far reaching implications to changing the way Twts are identified here to be "location addressed" that I'm quite worried about the amount of effort would be required to change yarnd here.

stats
yarn.meff.me
View Thread
🧮 USERS:1 FEEDS:2 TWTS:1100 ARCHIVED:79197 CACHE:2589 FOLLOWERS:17 FOLLOWING:14
prologic
twtxt.net
View Thread
@mckinley Yes I have, however I'm not counting that because even using "Cloud" is not labor free.
prologic
twtxt.net
View Thread
@mckinley Yes I have, however I'm not counting that because even using "Cloud" is not labor free.
prologic
twtxt.net
View Thread
@aelaraji We digits it out 🤣 @lyse 's little hack was good but only temporary 🤣
prologic
twtxt.net
View Thread
@aelaraji We digits it out 🤣 @lyse 's little hack was good but only temporary 🤣
prologic
twtxt.net
View Thread
@sorenpeter Lins of agree with dealing with this kind of social nonsense which we've all done in the past 🤣
prologic
twtxt.net
View Thread
@sorenpeter Lins of agree with dealing with this kind of social nonsense which we've all done in the past 🤣
prologic
twtxt.net
View Thread
@movq I think your scenario doesn't account for clients and their storage. The scenario described only really affects clients that come along later. Even then they would also be able to re-fetch mossing Twts from peers or even a search engine to fill in the gaps.
prologic
twtxt.net
View Thread
@movq I think your scenario doesn't account for clients and their storage. The scenario described only really affects clients that come along later. Even then they would also be able to re-fetch mossing Twts from peers or even a search engine to fill in the gaps.
bender
twtxt.net
View Thread
@lyse makes me want to be there. Sunny, but “feels” fresh. Lovely!
bender
twtxt.net
View Thread
@aelaraji it looks good! Where do you see those notifications?
sorenpeter
darch.dk
View Thread
@movq I cases of these kind of "abuse" of social trust. Then I think people should just delete their replies, unfollow the troll and leave them to shouting in the void. This is a inter-social issue, not a technical issue. Anything can be spoofed. We are not building a banking app, we are just having conversation and if trust are broken then communication breaks down. These edge-cases are all very hypothetical and not something I think we need to solve with technology.
sorenpeter
darch.dk
View Thread
@movq I cases of these kind of "abuse" of social trust. Then I think people should just delete their replies, unfollow the troll and leave them to shouting in the void. This is a inter-social issue, not a technical issue. Anything can be spoofed. We are not building a banking app, we are just having conversation and if trust are broken then communication breaks down. These edge-cases are all very hypothetical and not something I think we need to solve with technology.
sorenpeter
darch.dk
View Thread
@movq I cases of these kind of "abuse" of social trust. Then I think people should just delete their replies, unfollow the troll and leave them to shouting in the void. This is a inter-social issue, not a technical issue. Anything can be spoofed. We are not building a banking app, we are just having conversation and if trust are broken then communication breaks down. These edge-cases are all very hypothetical and not something I think we need to solve with technology.
sorenpeter
darch.dk
View Thread
@movq I cases of these kind of "abuse" of social trust. Then I think people should just delete their replies, unfollow the troll and leave them to shouting in the void. This is a inter-social issue, not a technical issue. Anything can be spoofed. We are not building a banking app, we are just having conversation and if trust are broken then communication breaks down. These edge-cases are all very hypothetical and not something I think we need to solve with technology.
sorenpeter
darch.dk
View Thread
Been thinking about it for the last couple of days and I would say we can make do with the shorter (#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?
sorenpeter
darch.dk
View Thread
Been thinking about it for the last couple of days and I would say we can make do with the shorter (#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?
sorenpeter
darch.dk
View Thread
Been thinking about it for the last couple of days and I would say we can make do with the shorter (#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?
sorenpeter
darch.dk
View Thread
Been thinking about it for the last couple of days and I would say we can make do with the shorter (#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?
aelaraji
aelaraji.com
View Thread
@prologic 🕵🏻 Hint: it was a twt about stolen property...
aelaraji
aelaraji.com
View Thread
@prologic 🕵🏻 Hint: it was a twt about stolen property...
aelaraji
aelaraji.com
View Thread
@prologic 🕵🏻 Hint: it was a twt about stolen property...
lyse
lyse.isobeef.org
View Thread
@movq Awesome, thank you very much! I'll have a look at it tomorrow.
mckinley-cc
mckinley.cc
View Thread
...while chasing the clouds away.
@jo
comam.es
View Thread
[47°09′39″S, 126°43′44″W] Raw reading: 0x66EF17B1, offset +/-5
lyse
lyse.isobeef.org
View Thread
It was beautiful in nature: https://lyse.isobeef.org/waldspaziergang-2024-09-21/

Fresh hay bales on a field
aelaraji
aelaraji.com
View Thread
I have just made yet _another_ convoluted twtxt notifications script! Feeling like an old dog learning new tricks! 🤣

A screenshot of two "Dunst" notifications sent from a bash script showing how many unread twts and twtxt mentions I have in my inbox.
aelaraji
aelaraji.com
View Thread
I have just made yet _another_ convoluted twtxt notifications script! Feeling like an old dog learning new tricks! 🤣

A screenshot of two "Dunst" notifications sent from a bash script showing how many unread twts and twtxt mentions I have in my inbox.
aelaraji
aelaraji.com
View Thread
I have just made yet _another_ convoluted twtxt notifications script! Feeling like an old dog learning new tricks! 🤣

A screenshot of two "Dunst" notifications sent from a bash script showing how many unread twts and twtxt mentions I have in my inbox.
movq
www.uninformativ.de
View Thread
Alright, let’s call attention to this fact and let’s hear your opinions on this:

With the (replyto:…) proposal, clients cannot indicate that a twt was edited *in the long run*. Clients can, of course, show that *right now*, but when they clean their cache and refetch feeds, the information is lost. This can be abused by malicious actors *if sufficient time has passed* (clients must have purged their cache): Malicious actors can change root twts and thus change the meaning of thread/replies.

Is this a showstopper for you? 🤔
movq
www.uninformativ.de
View Thread
Alright, let’s call attention to this fact and let’s hear your opinions on this:

With the (replyto:…) proposal, clients cannot indicate that a twt was edited *in the long run*. Clients can, of course, show that *right now*, but when they clean their cache and refetch feeds, the information is lost. This can be abused by malicious actors *if sufficient time has passed* (clients must have purged their cache): Malicious actors can change root twts and thus change the meaning of thread/replies.

Is this a showstopper for you? 🤔
movq
www.uninformativ.de
View Thread
Alright, let’s call attention to this fact and let’s hear your opinions on this:

With the (replyto:…) proposal, clients cannot indicate that a twt was edited *in the long run*. Clients can, of course, show that *right now*, but when they clean their cache and refetch feeds, the information is lost. This can be abused by malicious actors *if sufficient time has passed* (clients must have purged their cache): Malicious actors can change root twts and thus change the meaning of thread/replies.

Is this a showstopper for you? 🤔
movq
www.uninformativ.de
View Thread
Alright, let’s call attention to this fact and let’s hear your opinions on this:

With the (replyto:…) proposal, clients cannot indicate that a twt was edited *in the long run*. Clients can, of course, show that *right now*, but when they clean their cache and refetch feeds, the information is lost. This can be abused by malicious actors *if sufficient time has passed* (clients must have purged their cache): Malicious actors can change root twts and thus change the meaning of thread/replies.

Is this a showstopper for you? 🤔
movq
www.uninformativ.de
View Thread
@prologic Kind of. But the (edit:) spec has similar problems in its current form:

1. Post a normal twt with nonsense content, let’s say the content is just a dot “.”.
2. Post an update to that twt, this time filling it with actual content, let’s say: “Birds are great!”
3. Wait for people to reply to your twt (which is the edited one). You might get lots of replies along the lines of “ohhhh, yeah!” or “😍😍😍” or other stuff wholeheartedly agreeing with you.
4. Post another update to the first twt, again changing the content completely, let’s say: “The earth is flat!”
5. Delete your first update from your feed, the one with the birds. Not with (delete:), just remove the line.
6. There’s now a thread with lots of people agreeing to a twt that says “The earth is flat!”

You might be able to see that the original content was just a dot “.”, but the twt that people actually replied to is gone for good and no way to detect that.

This raises two questions:

- The easy question: What do we do when the twt that an (edit:) line refers to is removed *later on* from a feed? We would have to delete that original twt from our caches, including the edit operation. This should be part of the spec.
- The result being a thread without a root, just like it is today. That’s fine.
- The hard question: How do we deal with multiple (potentially malicious or misleading) edits? Do we even want to open that can of worms? People only ever use the original twt hash in their replies, so nobody really knows to which edited version they’re replying. That is very similar to the (replyto:) situation, I think. 🤔
movq
www.uninformativ.de
View Thread
@prologic Kind of. But the (edit:) spec has similar problems in its current form:

1. Post a normal twt with nonsense content, let’s say the content is just a dot “.”.
2. Post an update to that twt, this time filling it with actual content, let’s say: “Birds are great!”
3. Wait for people to reply to your twt (which is the edited one). You might get lots of replies along the lines of “ohhhh, yeah!” or “😍😍😍” or other stuff wholeheartedly agreeing with you.
4. Post another update to the first twt, again changing the content completely, let’s say: “The earth is flat!”
5. Delete your first update from your feed, the one with the birds. Not with (delete:), just remove the line.
6. There’s now a thread with lots of people agreeing to a twt that says “The earth is flat!”

You might be able to see that the original content was just a dot “.”, but the twt that people actually replied to is gone for good and no way to detect that.

This raises two questions:

- The easy question: What do we do when the twt that an (edit:) line refers to is removed *later on* from a feed? We would have to delete that original twt from our caches, including the edit operation. This should be part of the spec.
- The result being a thread without a root, just like it is today. That’s fine.
- The hard question: How do we deal with multiple (potentially malicious or misleading) edits? Do we even want to open that can of worms? People only ever use the original twt hash in their replies, so nobody really knows to which edited version they’re replying. That is very similar to the (replyto:) situation, I think. 🤔
movq
www.uninformativ.de
View Thread
@prologic Kind of. But the (edit:) spec has similar problems in its current form:

1. Post a normal twt with nonsense content, let’s say the content is just a dot “.”.
2. Post an update to that twt, this time filling it with actual content, let’s say: “Birds are great!”
3. Wait for people to reply to your twt (which is the edited one). You might get lots of replies along the lines of “ohhhh, yeah!” or “😍😍😍” or other stuff wholeheartedly agreeing with you.
4. Post another update to the first twt, again changing the content completely, let’s say: “The earth is flat!”
5. Delete your first update from your feed, the one with the birds. Not with (delete:), just remove the line.
6. There’s now a thread with lots of people agreeing to a twt that says “The earth is flat!”

You might be able to see that the original content was just a dot “.”, but the twt that people actually replied to is gone for good and no way to detect that.

This raises two questions:

- The easy question: What do we do when the twt that an (edit:) line refers to is removed *later on* from a feed? We would have to delete that original twt from our caches, including the edit operation. This should be part of the spec.
- The result being a thread without a root, just like it is today. That’s fine.
- The hard question: How do we deal with multiple (potentially malicious or misleading) edits? Do we even want to open that can of worms? People only ever use the original twt hash in their replies, so nobody really knows to which edited version they’re replying. That is very similar to the (replyto:) situation, I think. 🤔
movq
www.uninformativ.de
View Thread
@prologic Kind of. But the (edit:) spec has similar problems in its current form:

1. Post a normal twt with nonsense content, let’s say the content is just a dot “.”.
2. Post an update to that twt, this time filling it with actual content, let’s say: “Birds are great!”
3. Wait for people to reply to your twt (which is the edited one). You might get lots of replies along the lines of “ohhhh, yeah!” or “😍😍😍” or other stuff wholeheartedly agreeing with you.
4. Post another update to the first twt, again changing the content completely, let’s say: “The earth is flat!”
5. Delete your first update from your feed, the one with the birds. Not with (delete:), just remove the line.
6. There’s now a thread with lots of people agreeing to a twt that says “The earth is flat!”

You might be able to see that the original content was just a dot “.”, but the twt that people actually replied to is gone for good and no way to detect that.

This raises two questions:

- The easy question: What do we do when the twt that an (edit:) line refers to is removed *later on* from a feed? We would have to delete that original twt from our caches, including the edit operation. This should be part of the spec.
- The result being a thread without a root, just like it is today. That’s fine.
- The hard question: How do we deal with multiple (potentially malicious or misleading) edits? Do we even want to open that can of worms? People only ever use the original twt hash in their replies, so nobody really knows to which edited version they’re replying. That is very similar to the (replyto:) situation, I think. 🤔
@jo
comam.es
View Thread
[47°09′45″S, 126°43′55″W] Dosimeter overflow
prologic
twtxt.net
View Thread
@movq That's kind a problem though right?
prologic
twtxt.net
View Thread
@movq That's kind a problem though right?
prologic
twtxt.net
View Thread
@david 🤣🤣🤣
prologic
twtxt.net
View Thread
@david 🤣🤣🤣
movq
www.uninformativ.de
View Thread
@prologic

> I just realized the other big property you lose is:
>
> > What if someone completely changes the content of the root of the thread?
>
> Does the Subject reference the feed and timestamp only or the intent too?

Then the content of that root twt changes. Just like it would with (edit:…). The only difference is that you cannot go back to that person’s feed and find out what the original content was.

In other words, we can’t (reliably) show a little star * like on Mastodon to indicate edits.
movq
www.uninformativ.de
View Thread
@prologic

> I just realized the other big property you lose is:
>
> > What if someone completely changes the content of the root of the thread?
>
> Does the Subject reference the feed and timestamp only or the intent too?

Then the content of that root twt changes. Just like it would with (edit:…). The only difference is that you cannot go back to that person’s feed and find out what the original content was.

In other words, we can’t (reliably) show a little star * like on Mastodon to indicate edits.
movq
www.uninformativ.de
View Thread
@prologic

> I just realized the other big property you lose is:
>
> > What if someone completely changes the content of the root of the thread?
>
> Does the Subject reference the feed and timestamp only or the intent too?

Then the content of that root twt changes. Just like it would with (edit:…). The only difference is that you cannot go back to that person’s feed and find out what the original content was.

In other words, we can’t (reliably) show a little star * like on Mastodon to indicate edits.
movq
www.uninformativ.de
View Thread
@prologic

> I just realized the other big property you lose is:
>
> > What if someone completely changes the content of the root of the thread?
>
> Does the Subject reference the feed and timestamp only or the intent too?

Then the content of that root twt changes. Just like it would with (edit:…). The only difference is that you cannot go back to that person’s feed and find out what the original content was.

In other words, we can’t (reliably) show a little star * like on Mastodon to indicate edits.
movq
www.uninformativ.de
View Thread
@prologic

Regarding the URL changing issue: That is not a new issue and not addressed by either PR. Do you have some plans to solve this that only works with hashes? 🤔 Is it feed signing? I have to admit here, I forgot most about the feed signing ideas. 🙈

> - Twt Subjects lose their meaning

You mean existing threads in the past? Yeah.

> - Twt Subjects cannot be verified without looking up the feed.
> - Which may or may not exist anymore or may change.

Not sure what you mean? 🤔 But yes, things can change (that’s the point).

> - Two persons cannot reply to a Twt independently of each other anymore.

How so? 🤔 That would be a total show-stopper, I agree. But are you sure that’s going to happen? For example, if people were to reply to this very twt of yours, they would do this:

(replyto:https://twtxt.net/user/prologic/twtxt.txt,2024-09-21T15:22:18Z) foobar

Am I missing something?
movq
www.uninformativ.de
View Thread
@prologic

Regarding the URL changing issue: That is not a new issue and not addressed by either PR. Do you have some plans to solve this that only works with hashes? 🤔 Is it feed signing? I have to admit here, I forgot most about the feed signing ideas. 🙈

> - Twt Subjects lose their meaning

You mean existing threads in the past? Yeah.

> - Twt Subjects cannot be verified without looking up the feed.
> - Which may or may not exist anymore or may change.

Not sure what you mean? 🤔 But yes, things can change (that’s the point).

> - Two persons cannot reply to a Twt independently of each other anymore.

How so? 🤔 That would be a total show-stopper, I agree. But are you sure that’s going to happen? For example, if people were to reply to this very twt of yours, they would do this:

(replyto:https://twtxt.net/user/prologic/twtxt.txt,2024-09-21T15:22:18Z) foobar

Am I missing something?
movq
www.uninformativ.de
View Thread
@prologic

Regarding the URL changing issue: That is not a new issue and not addressed by either PR. Do you have some plans to solve this that only works with hashes? 🤔 Is it feed signing? I have to admit here, I forgot most about the feed signing ideas. 🙈

> - Twt Subjects lose their meaning

You mean existing threads in the past? Yeah.

> - Twt Subjects cannot be verified without looking up the feed.
> - Which may or may not exist anymore or may change.

Not sure what you mean? 🤔 But yes, things can change (that’s the point).

> - Two persons cannot reply to a Twt independently of each other anymore.

How so? 🤔 That would be a total show-stopper, I agree. But are you sure that’s going to happen? For example, if people were to reply to this very twt of yours, they would do this:

(replyto:https://twtxt.net/user/prologic/twtxt.txt,2024-09-21T15:22:18Z) foobar

Am I missing something?
movq
www.uninformativ.de
View Thread
@prologic

Regarding the URL changing issue: That is not a new issue and not addressed by either PR. Do you have some plans to solve this that only works with hashes? 🤔 Is it feed signing? I have to admit here, I forgot most about the feed signing ideas. 🙈

> - Twt Subjects lose their meaning

You mean existing threads in the past? Yeah.

> - Twt Subjects cannot be verified without looking up the feed.
> - Which may or may not exist anymore or may change.

Not sure what you mean? 🤔 But yes, things can change (that’s the point).

> - Two persons cannot reply to a Twt independently of each other anymore.

How so? 🤔 That would be a total show-stopper, I agree. But are you sure that’s going to happen? For example, if people were to reply to this very twt of yours, they would do this:

(replyto:https://twtxt.net/user/prologic/twtxt.txt,2024-09-21T15:22:18Z) foobar

Am I missing something?
prologic
twtxt.net
View Thread
I just realized the other big property you lose is:

> What if someone completely changes the content of the root of the thread?

Does the Subject reference the feed and timestamp only or the intent too?
prologic
twtxt.net
View Thread
I just realized the other big property you lose is:

> What if someone completely changes the content of the root of the thread?

Does the Subject reference the feed and timestamp only or the intent too?
david
collantes.us
View Thread
@prologic "*Even though there are _some_ 😉 that have different views on this 🤣*" --- coyly raises the hand... LOL.*
david
collantes.us
View Thread
@prologic "*Even though there are _some_ 😉 that have different views on this 🤣*" --- coyly raises the hand... LOL.*
prologic
twtxt.net
View Thread
@bender Yeah I'll be honest here; I'm not going to be very happy if we go down this "location addressing" route;

- Twt Subjects lose their meaning.
- Twt Subjects cannot be verified without looking up the feed.
- Which may or may not exist anymore or may change.
- Two persons cannot reply to a Twt independently of each other anymore.

_and probably some other properties we'd stand to lose that I'm forgetting about..._
prologic
twtxt.net
View Thread
@bender Yeah I'll be honest here; I'm not going to be very happy if we go down this "location addressing" route;

- Twt Subjects lose their meaning.
- Twt Subjects cannot be verified without looking up the feed.
- Which may or may not exist anymore or may change.
- Two persons cannot reply to a Twt independently of each other anymore.

_and probably some other properties we'd stand to lose that I'm forgetting about..._
bender
twtxt.net
View Thread
I like the (replyto:...) as well. If the feed changes, well, it is the same as changing emails (and deleting the old one). No?
prologic
twtxt.net
View Thread
@movq One of the biggest reasons I don't like the (replyto:…) proposal (_location addressing vs. content addressing_) is that you just introduce a similar problem down the track, albeit rarer where if a feed changes its location, your thread's "identifiers" are no longer valid, unless those feed authors maintain strict URL redirects, etc. This potentially has the long-term effect of being rather fragile, as opposed to what we have now where an Edit just really causes a natural fork in the thread, which is how "forking" works in the first place.

I realise this is a bit pret here, and it probably doesn't matter a whole lot at our size. But I'm trying to think way ahead, to a point where Twtxt as a "thing" can continue to work and function decades from now, even with the extensions we've built. We've already proven for example that Twts and threads from ~4 years ago still work and are easily looked up haha 😝~
prologic
twtxt.net
View Thread
@movq One of the biggest reasons I don't like the (replyto:…) proposal (_location addressing vs. content addressing_) is that you just introduce a similar problem down the track, albeit rarer where if a feed changes its location, your thread's "identifiers" are no longer valid, unless those feed authors maintain strict URL redirects, etc. This potentially has the long-term effect of being rather fragile, as opposed to what we have now where an Edit just really causes a natural fork in the thread, which is how "forking" works in the first place.

I realise this is a bit pret here, and it probably doesn't matter a whole lot at our size. But I'm trying to think way ahead, to a point where Twtxt as a "thing" can continue to work and function decades from now, even with the extensions we've built. We've already proven for example that Twts and threads from ~4 years ago still work and are easily looked up haha 😝~
movq
www.uninformativ.de
View Thread
I’m still more in favor of (replyto:…). It’s easier to implement and the whole edits-breaking-threads thing resolves itself in a “natural” way without the need to *add* stuff to the protocol.

I’d love to try this out in practice to see how well it performs. 🤔 It’s all very theoretical at the moment.
movq
www.uninformativ.de
View Thread
I’m still more in favor of (replyto:…). It’s easier to implement and the whole edits-breaking-threads thing resolves itself in a “natural” way without the need to *add* stuff to the protocol.

I’d love to try this out in practice to see how well it performs. 🤔 It’s all very theoretical at the moment.
movq
www.uninformativ.de
View Thread
I’m still more in favor of (replyto:…). It’s easier to implement and the whole edits-breaking-threads thing resolves itself in a “natural” way without the need to *add* stuff to the protocol.

I’d love to try this out in practice to see how well it performs. 🤔 It’s all very theoretical at the moment.
movq
www.uninformativ.de
View Thread
I’m still more in favor of (replyto:…). It’s easier to implement and the whole edits-breaking-threads thing resolves itself in a “natural” way without the need to *add* stuff to the protocol.

I’d love to try this out in practice to see how well it performs. 🤔 It’s all very theoretical at the moment.
movq
www.uninformativ.de
View Thread
Guess you could say:

- (replyto:…) is twtxt-style
- (edit:…) and (delete:…) is Yarn-style
movq
www.uninformativ.de
View Thread
Guess you could say:

- (replyto:…) is twtxt-style
- (edit:…) and (delete:…) is Yarn-style
movq
www.uninformativ.de
View Thread
Guess you could say:

- (replyto:…) is twtxt-style
- (edit:…) and (delete:…) is Yarn-style
movq
www.uninformativ.de
View Thread
Guess you could say:

- (replyto:…) is twtxt-style
- (edit:…) and (delete:…) is Yarn-style
prologic
twtxt.net
View Thread
I just read the primary spec I'm strongly in support of and it's pretty rock solid for me 👌 💯
prologic
twtxt.net
View Thread
I just read the primary spec I'm strongly in support of and it's pretty rock solid for me 👌 💯
prologic
twtxt.net
View Thread
Do you recall what it was? I blame my maintenance window 🪟
prologic
twtxt.net
View Thread
Do you recall what it was? I blame my maintenance window 🪟
prologic
twtxt.net
View Thread
@bender Hmm what you replied to appears to be non-existent: https://twtxt.net/twt/pqst4ea
prologic
twtxt.net
View Thread
@bender Hmm what you replied to appears to be non-existent: https://twtxt.net/twt/pqst4ea
prologic
twtxt.net
View Thread
@movq I just saw thes come through! 🙏 Thank you very much, I'll definitely have a read tomorrow! 👌
prologic
twtxt.net
View Thread
@movq I just saw thes come through! 🙏 Thank you very much, I'll definitely have a read tomorrow! 👌
bender
twtxt.net
View Thread
@movq good job!
bender
twtxt.net
View Thread
Something’s broken.
movq
www.uninformativ.de
View Thread
Alright, before I go and watch Formula 1 😅, I made two PRs regarding the two “competing” ideas:

- https://git.mills.io/yarnsocial/yarn/pulls/1179 – (replyto:…)
- https://git.mills.io/yarnsocial/yarn/pulls/1180 – (edit:…) and (delete:…)

As a first step, this summarizes my current understanding. Please comment! 😊
movq
www.uninformativ.de
View Thread
Alright, before I go and watch Formula 1 😅, I made two PRs regarding the two “competing” ideas:

- https://git.mills.io/yarnsocial/yarn/pulls/1179 – (replyto:…)
- https://git.mills.io/yarnsocial/yarn/pulls/1180 – (edit:…) and (delete:…)

As a first step, this summarizes my current understanding. Please comment! 😊
movq
www.uninformativ.de
View Thread
Alright, before I go and watch Formula 1 😅, I made two PRs regarding the two “competing” ideas:

- https://git.mills.io/yarnsocial/yarn/pulls/1179 – (replyto:…)
- https://git.mills.io/yarnsocial/yarn/pulls/1180 – (edit:…) and (delete:…)

As a first step, this summarizes my current understanding. Please comment! 😊
movq
www.uninformativ.de
View Thread
Alright, before I go and watch Formula 1 😅, I made two PRs regarding the two “competing” ideas:

- https://git.mills.io/yarnsocial/yarn/pulls/1179 – (replyto:…)
- https://git.mills.io/yarnsocial/yarn/pulls/1180 – (edit:…) and (delete:…)

As a first step, this summarizes my current understanding. Please comment! 😊
bender
twtxt.net
View Thread
@prologic the one I relied to. It vanished now.
baldo
baldo.cat
View Thread
Muerte negra por caricia
/https://baldo.cat/media/photos/IMG_2053.jpeg) #catsoftwtxt
baldo
baldo.cat
View Thread
Muerte negra por caricia
#catsoftwtxt
baldo
baldo.cat
View Thread
Muerte negra por caricia
#catsoftwtxt
prologic
twtxt.net
View Thread
@bender Which reply was that? 🤔
prologic
twtxt.net
View Thread
@bender Which reply was that? 🤔
prologic
twtxt.net
View Thread
@bender Bahahahahaha 🤣
prologic
twtxt.net
View Thread
@bender Bahahahahaha 🤣
bender
twtxt.net
View Thread
@prologic where is the parent on your reply? 🧐🤔😅
bender
twtxt.net
View Thread
@prologic right, because it was deleted, and purged from cache, of course! Good try, mister, you are in trouble. Call the Yarn Police! 😂
prologic
twtxt.net
View Thread
Ever wondered what it would cost to self-hosted vs. use the cloud? Well I often doubt myself every time I look at hardware prices, and I know I have to do some hardware refresh soon™ for the Mills DC (_something I don't have a regular plan or budget for_), here's a rough ball park:

The Mills DC has cost me around ~$15k to build and maintain over the last ~10 years or so. Roughly speaking. I've never actually taken a Bill of Materials or anything, but I could if anyone is interested in more specifics.

The equivalent of resources if run in the "Cloud" would cost around:

- ~$1,000 for virtual machines
- ~$12000 for storage

So around ~$2,000/month to run.

Keep this in mind anytime anyone ever tries to con you into believing "Cloud is cheaper". It's not.~
prologic
twtxt.net
View Thread
Ever wondered what it would cost to self-hosted vs. use the cloud? Well I often doubt myself every time I look at hardware prices, and I know I have to do some hardware refresh soon™ for the Mills DC (_something I don't have a regular plan or budget for_), here's a rough ball park:

The Mills DC has cost me around ~$15k to build and maintain over the last ~10 years or so. Roughly speaking. I've never actually taken a Bill of Materials or anything, but I could if anyone is interested in more specifics.

The equivalent of resources if run in the "Cloud" would cost around:

- ~$1,000 for virtual machines
- ~$12000 for storage

So around ~$2,000/month to run.

Keep this in mind anytime anyone ever tries to con you into believing "Cloud is cheaper". It's not.~
prologic
twtxt.net
View Thread
@aelaraji This is one of the reasons why yarnd has a couple of settings with some sensible/sane defaults:

> I could already imagine a couple of extreme cases where, somewhere, in this peaceful world one’s exercise of freedom of speech could get them in Real trouble (if not danger) if found out, it wouldn’t necessarily have to involve something to do with Law or legal authorities. So, If someone asks, and maybe fearing fearing for… let’s just say ‘Their well being’, would it heart if a pod just purged their content if it’s serving it publicly (maybe relay the info to other pods) and call it a day? It doesn’t have to be about some law/convention somewhere … 🤷 I know! Too extreme, but I’ve seen news of people who’d gone to jail or got their lives ruined for as little as a silly joke. And it doesn’t even have to be about any of this.

There are two settings:


$ ./yarnd --help 2>&1 | grep max-cache
      --max-cache-fetchers int        set maximum numnber of fetchers to use for feed cache updates (default 10)
  -I, --max-cache-items int           maximum cache items (per feed source) of cached twts in memory (default 150)
  -C, --max-cache-ttl duration        maximum cache ttl (time-to-live) of cached twts in memory (default 336h0m0s)


So yarnd pods by default are designed to only keep Twts around publicly visible on either the anonymous Frontpage or Discover View or your Timeline or the feed's Timeline for up to 2 weeks with a maximum of 150 items, whichever get exceeded first. Any Twts over this are considered "old" and drop off the active cache.

It's a feature that my old man @off_grid_living was very strongly in support of, as was I back in the day of yarnd's design (_nothing particularly to do with Twtxt per se_) that I've to this day stuck by -- Even though there are _some_ 😉 that have different views on this 🤣
prologic
twtxt.net
View Thread
@aelaraji This is one of the reasons why yarnd has a couple of settings with some sensible/sane defaults:

> I could already imagine a couple of extreme cases where, somewhere, in this peaceful world one’s exercise of freedom of speech could get them in Real trouble (if not danger) if found out, it wouldn’t necessarily have to involve something to do with Law or legal authorities. So, If someone asks, and maybe fearing fearing for… let’s just say ‘Their well being’, would it heart if a pod just purged their content if it’s serving it publicly (maybe relay the info to other pods) and call it a day? It doesn’t have to be about some law/convention somewhere … 🤷 I know! Too extreme, but I’ve seen news of people who’d gone to jail or got their lives ruined for as little as a silly joke. And it doesn’t even have to be about any of this.

There are two settings:


$ ./yarnd --help 2>&1 | grep max-cache
      --max-cache-fetchers int        set maximum numnber of fetchers to use for feed cache updates (default 10)
  -I, --max-cache-items int           maximum cache items (per feed source) of cached twts in memory (default 150)
  -C, --max-cache-ttl duration        maximum cache ttl (time-to-live) of cached twts in memory (default 336h0m0s)


So yarnd pods by default are designed to only keep Twts around publicly visible on either the anonymous Frontpage or Discover View or your Timeline or the feed's Timeline for up to 2 weeks with a maximum of 150 items, whichever get exceeded first. Any Twts over this are considered "old" and drop off the active cache.

It's a feature that my old man @off_grid_living was very strongly in support of, as was I back in the day of yarnd's design (_nothing particularly to do with Twtxt per se_) that I've to this day stuck by -- Even though there are _some_ 😉 that have different views on this 🤣