# 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 15156
# self = https://watcher.sour.is?uri=https://www.uninformativ.de/twtxt.txt&offset=12775
# next = https://watcher.sour.is?uri=https://www.uninformativ.de/twtxt.txt&offset=12875
# prev = https://watcher.sour.is?uri=https://www.uninformativ.de/twtxt.txt&offset=12675
@prologic Okay. So it goes like this:
My client fetches a feed. It builds a map/hashmap/dictionary of all twts: Timestamps map to twt hashes. It then stores/shows the twts. It also stores the hashmap.
On the next fetch operation, the client re-processes all twts in the feed. It must now compare each timestamp to the previously built hashmap: Aha, timestamp T has now a twt hash of B instead of A, so this is an edited twt.
Did I understand that correctly so far? š¤
@prologic Okay. So it goes like this:
My client fetches a feed. It builds a map/hashmap/dictionary of all twts: Timestamps map to twt hashes. It then stores/shows the twts. It also stores the hashmap.
On the next fetch operation, the client re-processes all twts in the feed. It must now compare each timestamp to the previously built hashmap: Aha, timestamp T has now a twt hash of B instead of A, so this is an edited twt.
Did I understand that correctly so far? š¤
@prologic Okay. So it goes like this:
My client fetches a feed. It builds a map/hashmap/dictionary of all twts: Timestamps map to twt hashes. It then stores/shows the twts. It also stores the hashmap.
On the next fetch operation, the client re-processes all twts in the feed. It must now compare each timestamp to the previously built hashmap: Aha, timestamp T has now a twt hash of B instead of A, so this is an edited twt.
Did I understand that correctly so far? š¤
@prologic Any more details on the edit stuff? š¤
@prologic Any more details on the edit stuff? š¤
@prologic Any more details on the edit stuff? š¤
@prologic Any more details on the edit stuff? š¤
I have no intention of dropping support for Gopher or Gemini from jenny.
I have no intention of dropping support for Gopher or Gemini from jenny.
I have no intention of dropping support for Gopher or Gemini from jenny.
I have no intention of dropping support for Gopher or Gemini from jenny.
I might actually end up doing this excercise with our apprentices at work. You can use this as a starting point to teach *a ton* of things. š¤
I might actually end up doing this excercise with our apprentices at work. You can use this as a starting point to teach *a ton* of things. š¤
I might actually end up doing this excercise with our apprentices at work. You can use this as a starting point to teach *a ton* of things. š¤
I might actually end up doing this excercise with our apprentices at work. You can use this as a starting point to teach *a ton* of things. š¤
@prologic When I first started using twtxt, I was fascinated by the fact that itās just a simple text file. This is already undermined *a lot* today by us using multiline replies and Markdown and what not. Still, I would love to retain this property of it being just a file that needs very few external tools to maintain. (Jenny is quite bloated, one might argue. One of the reasons for even *starting* the jenny project was the calculation of hashes ā I was using a smaller, simpler toolchest before.)
If we were to use (replyto:ā¦), I could just copy and paste the required info into my text editor. With echo ā¦ | sha256sum | base64 (+ the truncation step), I have to open a new terminal, make sure the tab gets copied verbatim, make sure that thereās no trailing whitespace in the content, little details like that. It *is* more effort.
This probably isnāt the best argument for (replyto:ā¦), but it is *an* argument.
Would people do all this manually? I donāt know. Probably not. But part of the fascination with twtxt is that you *could* do it.
Iām speaking from a point of extreme minimalism here and all this isnāt strictly only related to (reply:ā¦). It just reflects my general view on twtxt. The more additional things we build on top, the less interesting twtxt becomes (for me). My goal would be to find solutions that require *less*. Like, donāt solve edits breaking threads by *adding* another protocol, but by rethinking the whole thing, finding the root cause, and maybe come up with something that doesnāt need another building block on top.
This is all I have to say for now. š Iām gonna let things cool off for a while.
@prologic When I first started using twtxt, I was fascinated by the fact that itās just a simple text file. This is already undermined *a lot* today by us using multiline replies and Markdown and what not. Still, I would love to retain this property of it being just a file that needs very few external tools to maintain. (Jenny is quite bloated, one might argue. One of the reasons for even *starting* the jenny project was the calculation of hashes ā I was using a smaller, simpler toolchest before.)
If we were to use (replyto:ā¦), I could just copy and paste the required info into my text editor. With echo ā¦ | sha256sum | base64 (+ the truncation step), I have to open a new terminal, make sure the tab gets copied verbatim, make sure that thereās no trailing whitespace in the content, little details like that. It *is* more effort.
This probably isnāt the best argument for (replyto:ā¦), but it is *an* argument.
Would people do all this manually? I donāt know. Probably not. But part of the fascination with twtxt is that you *could* do it.
Iām speaking from a point of extreme minimalism here and all this isnāt strictly only related to (reply:ā¦). It just reflects my general view on twtxt. The more additional things we build on top, the less interesting twtxt becomes (for me). My goal would be to find solutions that require *less*. Like, donāt solve edits breaking threads by *adding* another protocol, but by rethinking the whole thing, finding the root cause, and maybe come up with something that doesnāt need another building block on top.
This is all I have to say for now. š Iām gonna let things cool off for a while.
@prologic When I first started using twtxt, I was fascinated by the fact that itās just a simple text file. This is already undermined *a lot* today by us using multiline replies and Markdown and what not. Still, I would love to retain this property of it being just a file that needs very few external tools to maintain. (Jenny is quite bloated, one might argue. One of the reasons for even *starting* the jenny project was the calculation of hashes ā I was using a smaller, simpler toolchest before.)
If we were to use (replyto:ā¦), I could just copy and paste the required info into my text editor. With echo ā¦ | sha256sum | base64 (+ the truncation step), I have to open a new terminal, make sure the tab gets copied verbatim, make sure that thereās no trailing whitespace in the content, little details like that. It *is* more effort.
This probably isnāt the best argument for (replyto:ā¦), but it is *an* argument.
Would people do all this manually? I donāt know. Probably not. But part of the fascination with twtxt is that you *could* do it.
Iām speaking from a point of extreme minimalism here and all this isnāt strictly only related to (reply:ā¦). It just reflects my general view on twtxt. The more additional things we build on top, the less interesting twtxt becomes (for me). My goal would be to find solutions that require *less*. Like, donāt solve edits breaking threads by *adding* another protocol, but by rethinking the whole thing, finding the root cause, and maybe come up with something that doesnāt need another building block on top.
This is all I have to say for now. š Iām gonna let things cool off for a while.
@prologic When I first started using twtxt, I was fascinated by the fact that itās just a simple text file. This is already undermined *a lot* today by us using multiline replies and Markdown and what not. Still, I would love to retain this property of it being just a file that needs very few external tools to maintain. (Jenny is quite bloated, one might argue. One of the reasons for even *starting* the jenny project was the calculation of hashes ā I was using a smaller, simpler toolchest before.)
If we were to use (replyto:ā¦), I could just copy and paste the required info into my text editor. With echo ā¦ | sha256sum | base64 (+ the truncation step), I have to open a new terminal, make sure the tab gets copied verbatim, make sure that thereās no trailing whitespace in the content, little details like that. It *is* more effort.
This probably isnāt the best argument for (replyto:ā¦), but it is *an* argument.
Would people do all this manually? I donāt know. Probably not. But part of the fascination with twtxt is that you *could* do it.
Iām speaking from a point of extreme minimalism here and all this isnāt strictly only related to (reply:ā¦). It just reflects my general view on twtxt. The more additional things we build on top, the less interesting twtxt becomes (for me). My goal would be to find solutions that require *less*. Like, donāt solve edits breaking threads by *adding* another protocol, but by rethinking the whole thing, finding the root cause, and maybe come up with something that doesnāt need another building block on top.
This is all I have to say for now. š Iām gonna let things cool off for a while.
@prologic
> Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.
What youāre mentioning is *the primary reason*, imho, *for* location-based addressing. Youāre referencing a certain entry in a feed by its timestamp and the author is free to edit it. This solves the problem of broken threads after edits. And editing ārawā twtxt files is a very natural thing to do in the twtxt world (just not in *Yarn*ās world). Itās one of the core aspects and main selling points: You just have a file that you can edit with vi or whatever, done.
If you think changing content is a *vulnerability* of location-based addressing, then I get the feeling that thereās some kind of big misunderstanding going on here. š¤ Either on your end or on mine/ours. š¤
@prologic
> Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.
What youāre mentioning is *the primary reason*, imho, *for* location-based addressing. Youāre referencing a certain entry in a feed by its timestamp and the author is free to edit it. This solves the problem of broken threads after edits. And editing ārawā twtxt files is a very natural thing to do in the twtxt world (just not in *Yarn*ās world). Itās one of the core aspects and main selling points: You just have a file that you can edit with vi or whatever, done.
If you think changing content is a *vulnerability* of location-based addressing, then I get the feeling that thereās some kind of big misunderstanding going on here. š¤ Either on your end or on mine/ours. š¤
@prologic
> Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.
What youāre mentioning is *the primary reason*, imho, *for* location-based addressing. Youāre referencing a certain entry in a feed by its timestamp and the author is free to edit it. This solves the problem of broken threads after edits. And editing ārawā twtxt files is a very natural thing to do in the twtxt world (just not in *Yarn*ās world). Itās one of the core aspects and main selling points: You just have a file that you can edit with vi or whatever, done.
If you think changing content is a *vulnerability* of location-based addressing, then I get the feeling that thereās some kind of big misunderstanding going on here. š¤ Either on your end or on mine/ours. š¤
@prologic
> Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.
What youāre mentioning is *the primary reason*, imho, *for* location-based addressing. Youāre referencing a certain entry in a feed by its timestamp and the author is free to edit it. This solves the problem of broken threads after edits. And editing ārawā twtxt files is a very natural thing to do in the twtxt world (just not in *Yarn*ās world). Itās one of the core aspects and main selling points: You just have a file that you can edit with vi or whatever, done.
If you think changing content is a *vulnerability* of location-based addressing, then I get the feeling that thereās some kind of big misunderstanding going on here. š¤ Either on your end or on mine/ours. š¤
@aelaraji rsync -zaXAP is what I use all the time. But thatās all ā for the rest, I have to consult the manual. š
@aelaraji rsync -zaXAP is what I use all the time. But thatās all ā for the rest, I have to consult the manual. š
@aelaraji rsync -zaXAP is what I use all the time. But thatās all ā for the rest, I have to consult the manual. š
@aelaraji rsync -zaXAP is what I use all the time. But thatās all ā for the rest, I have to consult the manual. š
@lyse Yeah, itās different for everone. š
I, for one, am not particularly interested (yet) in the underlying hardware. Logic gates and stuff like that, thatās not my kind of thing. Maybe in the future, but thereās still more than enough to explore in the world of software. š
@lyse Yeah, itās different for everone. š
I, for one, am not particularly interested (yet) in the underlying hardware. Logic gates and stuff like that, thatās not my kind of thing. Maybe in the future, but thereās still more than enough to explore in the world of software. š
@lyse Yeah, itās different for everone. š
I, for one, am not particularly interested (yet) in the underlying hardware. Logic gates and stuff like that, thatās not my kind of thing. Maybe in the future, but thereās still more than enough to explore in the world of software. š
@lyse Yeah, itās different for everone. š
I, for one, am not particularly interested (yet) in the underlying hardware. Logic gates and stuff like that, thatās not my kind of thing. Maybe in the future, but thereās still more than enough to explore in the world of software. š
@eapl.me Aww. Well, I gave you a Follow on Mastodon (although that appears to be moastly Spanish š¤).
@eapl.me Aww. Well, I gave you a Follow on Mastodon (although that appears to be moastly Spanish š¤).
@eapl.me Aww. Well, I gave you a Follow on Mastodon (although that appears to be moastly Spanish š¤).
@eapl.me Aww. Well, I gave you a Follow on Mastodon (although that appears to be moastly Spanish š¤).
@falsifian You had me there for a second. š
I have to admit, even though I knew they existed, I never had a look at Leahās mail tools. Just gave mthread a spin and this is crazy fast. š¤Æ Tempting!
@falsifian You had me there for a second. š
I have to admit, even though I knew they existed, I never had a look at Leahās mail tools. Just gave mthread a spin and this is crazy fast. š¤Æ Tempting!
@falsifian You had me there for a second. š
I have to admit, even though I knew they existed, I never had a look at Leahās mail tools. Just gave mthread a spin and this is crazy fast. š¤Æ Tempting!
@falsifian You had me there for a second. š
I have to admit, even though I knew they existed, I never had a look at Leahās mail tools. Just gave mthread a spin and this is crazy fast. š¤Æ Tempting!
@prologic A factor of 5 is hard to believe, to be honest. Especially disk usage. I know nothing about the internals of yarnd, but still.
If this constitutes a hard ānoā to the proposal, then I think we donāt need to discuss it further.
@prologic A factor of 5 is hard to believe, to be honest. Especially disk usage. I know nothing about the internals of yarnd, but still.
If this constitutes a hard ānoā to the proposal, then I think we donāt need to discuss it further.
@prologic A factor of 5 is hard to believe, to be honest. Especially disk usage. I know nothing about the internals of yarnd, but still.
If this constitutes a hard ānoā to the proposal, then I think we donāt need to discuss it further.
@prologic A factor of 5 is hard to believe, to be honest. Especially disk usage. I know nothing about the internals of yarnd, but still.
If this constitutes a hard ānoā to the proposal, then I think we donāt need to discuss it further.
@prologic Whatās that in absolute numbers? My ~/Mail/twt is currently 26 MB in size. Increase that by 20% and we get 31.2 MB.
I donāt buy the argument with 2025 bytes. This worst case scenario is not relevant in practice.
@prologic Whatās that in absolute numbers? My ~/Mail/twt is currently 26 MB in size. Increase that by 20% and we get 31.2 MB.
I donāt buy the argument with 2025 bytes. This worst case scenario is not relevant in practice.
@prologic Whatās that in absolute numbers? My ~/Mail/twt is currently 26 MB in size. Increase that by 20% and we get 31.2 MB.
I donāt buy the argument with 2025 bytes. This worst case scenario is not relevant in practice.
@prologic Whatās that in absolute numbers? My ~/Mail/twt is currently 26 MB in size. Increase that by 20% and we get 31.2 MB.
I donāt buy the argument with 2025 bytes. This worst case scenario is not relevant in practice.
Itās a different story when you just publish a twtxt file, I think. The question here is: When you publish a twt and donāt like it anymore and want to delete it, do you have the *right* to *force* others to delete it? (Not in a technical manner, but by sueing them.) What does the GDPR have to say about that? Not a clue. š
Itās a different story when you just publish a twtxt file, I think. The question here is: When you publish a twt and donāt like it anymore and want to delete it, do you have the *right* to *force* others to delete it? (Not in a technical manner, but by sueing them.) What does the GDPR have to say about that? Not a clue. š
Itās a different story when you just publish a twtxt file, I think. The question here is: When you publish a twt and donāt like it anymore and want to delete it, do you have the *right* to *force* others to delete it? (Not in a technical manner, but by sueing them.) What does the GDPR have to say about that? Not a clue. š
Itās a different story when you just publish a twtxt file, I think. The question here is: When you publish a twt and donāt like it anymore and want to delete it, do you have the *right* to *force* others to delete it? (Not in a technical manner, but by sueing them.) What does the GDPR have to say about that? Not a clue. š
@xuu I *think* it is more tricky than that.
https://commission.europa.eu/law/law-topic/data-protection/reform/rules-business-and-organisations/application-regulation/who-does-data-protection-law-apply_en
āA company *or entity* ā¦ā
Also, as I understand it, āpersonal or household activityā (as you called it) is rather strict: An example could be you uploading photos to a webspace behind HTTP basic auth and sending that link to a friend. So, yes, a webserver is involved and you process your friendās data (e.g., when did he access your files), but itās just between you and him. But if you were to publish these photos publicly on a webserver that anyone can access, then itās a different story ā even though you could say that āthis is just my personal hobby, not related to any job or moneyā.
If you operate a public Yarn pod and *if you accept registrations from other users*, then Iām pretty sure the GDPR applies. š¤ You process personal data and you donāt really know these people. Itās not a personal/private thing anymore.
@xuu I *think* it is more tricky than that.
https://commission.europa.eu/law/law-topic/data-protection/reform/rules-business-and-organisations/application-regulation/who-does-data-protection-law-apply_en
āA company *or entity* ā¦ā
Also, as I understand it, āpersonal or household activityā (as you called it) is rather strict: An example could be you uploading photos to a webspace behind HTTP basic auth and sending that link to a friend. So, yes, a webserver is involved and you process your friendās data (e.g., when did he access your files), but itās just between you and him. But if you were to publish these photos publicly on a webserver that anyone can access, then itās a different story ā even though you could say that āthis is just my personal hobby, not related to any job or moneyā.
If you operate a public Yarn pod and *if you accept registrations from other users*, then Iām pretty sure the GDPR applies. š¤ You process personal data and you donāt really know these people. Itās not a personal/private thing anymore.
@xuu I *think* it is more tricky than that.
https://commission.europa.eu/law/law-topic/data-protection/reform/rules-business-and-organisations/application-regulation/who-does-data-protection-law-apply_en
āA company *or entity* ā¦ā
Also, as I understand it, āpersonal or household activityā (as you called it) is rather strict: An example could be you uploading photos to a webspace behind HTTP basic auth and sending that link to a friend. So, yes, a webserver is involved and you process your friendās data (e.g., when did he access your files), but itās just between you and him. But if you were to publish these photos publicly on a webserver that anyone can access, then itās a different story ā even though you could say that āthis is just my personal hobby, not related to any job or moneyā.
If you operate a public Yarn pod and *if you accept registrations from other users*, then Iām pretty sure the GDPR applies. š¤ You process personal data and you donāt really know these people. Itās not a personal/private thing anymore.
@xuu I *think* it is more tricky than that.
https://commission.europa.eu/law/law-topic/data-protection/reform/rules-business-and-organisations/application-regulation/who-does-data-protection-law-apply_en
āA company *or entity* ā¦ā
Also, as I understand it, āpersonal or household activityā (as you called it) is rather strict: An example could be you uploading photos to a webspace behind HTTP basic auth and sending that link to a friend. So, yes, a webserver is involved and you process your friendās data (e.g., when did he access your files), but itās just between you and him. But if you were to publish these photos publicly on a webserver that anyone can access, then itās a different story ā even though you could say that āthis is just my personal hobby, not related to any job or moneyā.
If you operate a public Yarn pod and *if you accept registrations from other users*, then Iām pretty sure the GDPR applies. š¤ You process personal data and you donāt really know these people. Itās not a personal/private thing anymore.
@lyse Wet and warm, yeah. š«¤ There were flies everywhere, lots of them, on all windows of the apartment. Never seen anything like that. š³šŖ° Like the building was a dead carcass. š
@lyse Wet and warm, yeah. š«¤ There were flies everywhere, lots of them, on all windows of the apartment. Never seen anything like that. š³šŖ° Like the building was a dead carcass. š
@lyse Wet and warm, yeah. š«¤ There were flies everywhere, lots of them, on all windows of the apartment. Never seen anything like that. š³šŖ° Like the building was a dead carcass. š
@lyse Wet and warm, yeah. š«¤ There were flies everywhere, lots of them, on all windows of the apartment. Never seen anything like that. š³šŖ° Like the building was a dead carcass. š
There are *so many* insects this year. Flies, ants, bugs. This isnāt normal. Itās almost like the ecosystem is getting out of balance.
There are *so many* insects this year. Flies, ants, bugs. This isnāt normal. Itās almost like the ecosystem is getting out of balance.
There are *so many* insects this year. Flies, ants, bugs. This isnāt normal. Itās almost like the ecosystem is getting out of balance.
There are *so many* insects this year. Flies, ants, bugs. This isnāt normal. Itās almost like the ecosystem is getting out of balance.
@prologic
> This scope of changes is much easier to implement for yarnd and *I suspect jenny too.*
No, (edit:) is a lot of work for jenny and also adds a lot of overhead.
Right now, jenny itself has no idea which twt hashes are present on which feed, because it doesnāt need to. This information only exists in the mail files. This means I canāt check if an (edit:) operation is legal. jenny will have to get an sqlite database (or read/parse/write 1-2 MB of JSON on every invocation, which isnāt great either).
Iāve already spent several hours this morning rewriting the feed fetching/parsing code in an effort to pave the way to even be *able* to support any of this. Iāll spare you the details. Until now, twts were individual items in a feed, they could be processed in any order and they didnāt reference each other *from jennys point of view*. A lot of the heavy lifting happens in the mail client.
Honestly, the database thing bugs me the most. The whole concept of ājust create some mail filesā doesnāt really work anymore. I now have to duplicate state between the mail files and an internal database. This is a big āmehā.
Of course, if we were to switch to location-based addressing, then *you* would have to do a lot of work. Thereās no easy way out.
Maybe I could say jenny does not support (edit:) for now. Thatās the good thing about this proposal: I donāt have to implement it right away. Users will see spurious twts (or I could hide them as a workaround) and they wonāt see twt updates, but nothing will break.
@prologic
> This scope of changes is much easier to implement for yarnd and *I suspect jenny too.*
No, (edit:) is a lot of work for jenny and also adds a lot of overhead.
Right now, jenny itself has no idea which twt hashes are present on which feed, because it doesnāt need to. This information only exists in the mail files. This means I canāt check if an (edit:) operation is legal. jenny will have to get an sqlite database (or read/parse/write 1-2 MB of JSON on every invocation, which isnāt great either).
Iāve already spent several hours this morning rewriting the feed fetching/parsing code in an effort to pave the way to even be *able* to support any of this. Iāll spare you the details. Until now, twts were individual items in a feed, they could be processed in any order and they didnāt reference each other *from jennys point of view*. A lot of the heavy lifting happens in the mail client.
Honestly, the database thing bugs me the most. The whole concept of ājust create some mail filesā doesnāt really work anymore. I now have to duplicate state between the mail files and an internal database. This is a big āmehā.
Of course, if we were to switch to location-based addressing, then *you* would have to do a lot of work. Thereās no easy way out.
Maybe I could say jenny does not support (edit:) for now. Thatās the good thing about this proposal: I donāt have to implement it right away. Users will see spurious twts (or I could hide them as a workaround) and they wonāt see twt updates, but nothing will break.
@prologic
> This scope of changes is much easier to implement for yarnd and *I suspect jenny too.*
No, (edit:) is a lot of work for jenny and also adds a lot of overhead.
Right now, jenny itself has no idea which twt hashes are present on which feed, because it doesnāt need to. This information only exists in the mail files. This means I canāt check if an (edit:) operation is legal. jenny will have to get an sqlite database (or read/parse/write 1-2 MB of JSON on every invocation, which isnāt great either).
Iāve already spent several hours this morning rewriting the feed fetching/parsing code in an effort to pave the way to even be *able* to support any of this. Iāll spare you the details. Until now, twts were individual items in a feed, they could be processed in any order and they didnāt reference each other *from jennys point of view*. A lot of the heavy lifting happens in the mail client.
Honestly, the database thing bugs me the most. The whole concept of ājust create some mail filesā doesnāt really work anymore. I now have to duplicate state between the mail files and an internal database. This is a big āmehā.
Of course, if we were to switch to location-based addressing, then *you* would have to do a lot of work. Thereās no easy way out.
Maybe I could say jenny does not support (edit:) for now. Thatās the good thing about this proposal: I donāt have to implement it right away. Users will see spurious twts (or I could hide them as a workaround) and they wonāt see twt updates, but nothing will break.
@prologic
> This scope of changes is much easier to implement for yarnd and *I suspect jenny too.*
No, (edit:) is a lot of work for jenny and also adds a lot of overhead.
Right now, jenny itself has no idea which twt hashes are present on which feed, because it doesnāt need to. This information only exists in the mail files. This means I canāt check if an (edit:) operation is legal. jenny will have to get an sqlite database (or read/parse/write 1-2 MB of JSON on every invocation, which isnāt great either).
Iāve already spent several hours this morning rewriting the feed fetching/parsing code in an effort to pave the way to even be *able* to support any of this. Iāll spare you the details. Until now, twts were individual items in a feed, they could be processed in any order and they didnāt reference each other *from jennys point of view*. A lot of the heavy lifting happens in the mail client.
Honestly, the database thing bugs me the most. The whole concept of ājust create some mail filesā doesnāt really work anymore. I now have to duplicate state between the mail files and an internal database. This is a big āmehā.
Of course, if we were to switch to location-based addressing, then *you* would have to do a lot of work. Thereās no easy way out.
Maybe I could say jenny does not support (edit:) for now. Thatās the good thing about this proposal: I donāt have to implement it right away. Users will see spurious twts (or I could hide them as a workaround) and they wonāt see twt updates, but nothing will break.
@sorenpeter No, we donāt need both. They are competing proposals and only one of them should get merged. š The format (#<DATETIME URL>) would also work, yeah.
@sorenpeter No, we donāt need both. They are competing proposals and only one of them should get merged. š The format (#<DATETIME URL>) would also work, yeah.
@sorenpeter No, we donāt need both. They are competing proposals and only one of them should get merged. š The format (#<DATETIME URL>) would also work, yeah.
@sorenpeter No, we donāt need both. They are competing proposals and only one of them should get merged. š The format (#<DATETIME URL>) would also work, yeah.
@sorenpeter Yes, fully agreed.
Personally, I am not really concerned about malicious actors here. Some may see that as naive. But if someone turns out to be an idiot, I unfollow their feed and delete my replies to them, done. (Something like (replyto:ā¦) would even make it trivial to find all my replies to a particular feed and nuke them. Could be done with sed.)
For the same reason, GPG signed feeds never took off. It just doesnāt matter. twtxt is small and nieche and that wonāt change anytime soon, I think. We only have to make sure that we donāt open the gates for *massive spam* and I think weāre safe on that.
Itās easy to get lost in these scenarios and overshoot the target.
@sorenpeter Yes, fully agreed.
Personally, I am not really concerned about malicious actors here. Some may see that as naive. But if someone turns out to be an idiot, I unfollow their feed and delete my replies to them, done. (Something like (replyto:ā¦) would even make it trivial to find all my replies to a particular feed and nuke them. Could be done with sed.)
For the same reason, GPG signed feeds never took off. It just doesnāt matter. twtxt is small and nieche and that wonāt change anytime soon, I think. We only have to make sure that we donāt open the gates for *massive spam* and I think weāre safe on that.
Itās easy to get lost in these scenarios and overshoot the target.
@sorenpeter Yes, fully agreed.
Personally, I am not really concerned about malicious actors here. Some may see that as naive. But if someone turns out to be an idiot, I unfollow their feed and delete my replies to them, done. (Something like (replyto:ā¦) would even make it trivial to find all my replies to a particular feed and nuke them. Could be done with sed.)
For the same reason, GPG signed feeds never took off. It just doesnāt matter. twtxt is small and nieche and that wonāt change anytime soon, I think. We only have to make sure that we donāt open the gates for *massive spam* and I think weāre safe on that.
Itās easy to get lost in these scenarios and overshoot the target.
@sorenpeter Yes, fully agreed.
Personally, I am not really concerned about malicious actors here. Some may see that as naive. But if someone turns out to be an idiot, I unfollow their feed and delete my replies to them, done. (Something like (replyto:ā¦) would even make it trivial to find all my replies to a particular feed and nuke them. Could be done with sed.)
For the same reason, GPG signed feeds never took off. It just doesnāt matter. twtxt is small and nieche and that wonāt change anytime soon, I think. We only have to make sure that we donāt open the gates for *massive spam* and I think weāre safe on that.
Itās easy to get lost in these scenarios and overshoot the target.
@prologic Yeah. I guess no matter what we do, either one of us has to do a lot of work on his respective software. š
The (absolute) impact on Yarn is probably bigger than that on jenny, simply because Yarn is a much larger piece of software to begin with.
Iāll begin experimenting in jenny with Update Commands and see how bad it gets. Iāve already determined that my storage model wouldnāt work anymore. Itās all *doable*, but, like you, Iām not that happy with all the consequences. š
@prologic Yeah. I guess no matter what we do, either one of us has to do a lot of work on his respective software. š
The (absolute) impact on Yarn is probably bigger than that on jenny, simply because Yarn is a much larger piece of software to begin with.
Iāll begin experimenting in jenny with Update Commands and see how bad it gets. Iāve already determined that my storage model wouldnāt work anymore. Itās all *doable*, but, like you, Iām not that happy with all the consequences. š
@prologic Yeah. I guess no matter what we do, either one of us has to do a lot of work on his respective software. š
The (absolute) impact on Yarn is probably bigger than that on jenny, simply because Yarn is a much larger piece of software to begin with.
Iāll begin experimenting in jenny with Update Commands and see how bad it gets. Iāve already determined that my storage model wouldnāt work anymore. Itās all *doable*, but, like you, Iām not that happy with all the consequences. š
@prologic Yeah. I guess no matter what we do, either one of us has to do a lot of work on his respective software. š
The (absolute) impact on Yarn is probably bigger than that on jenny, simply because Yarn is a much larger piece of software to begin with.
Iāll begin experimenting in jenny with Update Commands and see how bad it gets. Iāve already determined that my storage model wouldnāt work anymore. Itās all *doable*, but, like you, Iām not that happy with all the consequences. š
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? š¤
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? š¤
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? š¤
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? š¤