@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person.
@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions:(#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person.
@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
ssh-keygen -Y sign or ssh-keygen -Y verify tools already available? Maybe in combination with @xuu 's idea of generating a random unique ID for your feed, say # id = and signing it with your ED25519 key? 🔑
ssh-keygen -Y sign or ssh-keygen -Y verify tools already available? Maybe in combination with @xuu 's idea of generating a random unique ID for your feed, say # id = and signing it with your ED25519 key? 🔑
# url = changes in your feed?> Whatever gets used, it would be nice to be able to rotate identities. I like @lyse’s idea for that.
# url = changes in your feed?> Whatever gets used, it would be nice to be able to rotate identities. I like @lyse’s idea for that.
1. It minimizes I/O amplification by separating keys and values, allowing for more efficient storage and retrieval.
2. The design leverages the SSD's performance characteristics, utilizing sequential writes and parallel random reads to enhance throughput and reduce latency.
3. WiscKey maintains excellent insert and lookup performance while improving SSD lifespan by reducing the number of erase cycles required.
1. It minimizes I/O amplification by separating keys and values, allowing for more efficient storage and retrieval.
2. The design leverages the SSD's performance characteristics, utilizing sequential writes and parallel random reads to enhance throughput and reduce latency.
3. WiscKey maintains excellent insert and lookup performance while improving SSD lifespan by reducing the number of erase cycles required.
1. Separation of keys from values, with only keys stored in the LSM-tree and values in a separate log file.
2. Utilization of the parallel random-read characteristic of SSD devices to handle unsorted values during range queries.
3. Implementation of unique crash-consistency techniques to manage the value log efficiently.
4. Optimization of performance by removing the LSM-tree log without sacrificing consistency, reducing system-call overhead from small writes.
1. Separation of keys from values, with only keys stored in the LSM-tree and values in a separate log file.
2. Utilization of the parallel random-read characteristic of SSD devices to handle unsorted values during range queries.
3. Implementation of unique crash-consistency techniques to manage the value log efficiently.
4. Optimization of performance by removing the LSM-tree log without sacrificing consistency, reducing system-call overhead from small writes.
- Authors: Lanyue Lu, Thanumalayan Sankaranarayana Pillai, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau
- Conference: 14th USENIX Conference on File and Storage Technologies (FAST '16)
- Key Concept: WiscKey is a key-value store that separates keys from values to minimize I/O amplification, optimizing performance for SSDs.
- Performance: WiscKey outperforms LevelDB and RocksDB in various workloads, achieving up to 111× faster loading and improved random lookup speeds.
- Design Goals: Focus on low write/read amplification, SSD optimization, and support for modern features like range queries.
- Authors: Lanyue Lu, Thanumalayan Sankaranarayana Pillai, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau
- Conference: 14th USENIX Conference on File and Storage Technologies (FAST '16)
- Key Concept: WiscKey is a key-value store that separates keys from values to minimize I/O amplification, optimizing performance for SSDs.
- Performance: WiscKey outperforms LevelDB and RocksDB in various workloads, achieving up to 111× faster loading and improved random lookup speeds.
- Design Goals: Focus on low write/read amplification, SSD optimization, and support for modern features like range queries.
--fetch-context doesn’t go back into archived feeds … 🤦
--fetch-context doesn’t go back into archived feeds … 🤦
--fetch-context doesn’t go back into archived feeds … 🤦
--fetch-context doesn’t go back into archived feeds … 🤦
jenny renders this:
@quark This is what I get. 🤔
@quark This is what I get. 🤔
@quark This is what I get. 🤔
@quark This is what I get. 🤔
jenny:
From: quark <quark>
Subject: (#o) @prologic this was your first twtxt. Cool! :-P
Date: Mon, 16 Sep 2024 12:42:27 -0400
Message-Id: <k7imvia@twtxt>
X-twtxt-feed-url: https://ferengi.one/twtxt.txt
(#o) @<prologic https://twtxt.net/user/prologic/twtxt.txt> this was your first twtxt. Cool! :-P
jenny:
From: quark <quark>
Subject: (#o) @prologic this was your first twtxt. Cool! :-P
Date: Mon, 16 Sep 2024 12:42:27 -0400
Message-Id: <k7imvia@twtxt>
X-twtxt-feed-url: https://ferengi.one/twtxt.txt
(#o) @<prologic https://twtxt.net/user/prologic/twtxt.txt> this was your first twtxt. Cool! :-P
From: prologic <prologic>
Subject: Hello World! 😊
Date: Sat, 18 Jul 2020 08:39:52 -0400
Message-Id: <o6dsrga>
X-twtxt-feed-url: https://twtxt.net/user/prologic/twtxt.txt
Hello World! 😊
And see how the hash shows... Is it because that hash isn't longer used?
From: prologic <prologic>
Subject: Hello World! 😊
Date: Sat, 18 Jul 2020 08:39:52 -0400
Message-Id: <o6dsrga>
X-twtxt-feed-url: https://twtxt.net/user/prologic/twtxt.txt
Hello World! 😊
And see how the hash shows... Is it because that hash isn't longer used?
Jenny has to look for the metadata fields, it must find the
# prev = ... line. To do so, I naively wrote something along these lines:
for line in content.splitlines():
if line.startswith('# prev = '):
...
Problem is, we use \u2028 a lot in twtxt feeds and Python interprets those as line separators as well. That’s not what we want here. Jenny must only split at a
\n.Now @prologic had a quote/copy of some of his metadata fields in a twt. Like so:
# prev = foo bar
Perfectly legitimate, but now jenny found the
# prev = *twice* (once in the actual header, once in a twt), didn’t know what to do, and thus did not fetch the archived feeds. 🤦Should be fixed in this commit: https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
Jenny has to look for the metadata fields, it must find the
# prev = ... line. To do so, I naively wrote something along these lines:
for line in content.splitlines():
if line.startswith('# prev = '):
...
Problem is, we use \u2028 a lot in twtxt feeds and Python interprets those as line separators as well. That’s not what we want here. Jenny must only split at a
\n.Now @prologic had a quote/copy of some of his metadata fields in a twt. Like so:
# prev = foo bar
Perfectly legitimate, but now jenny found the
# prev = *twice* (once in the actual header, once in a twt), didn’t know what to do, and thus did not fetch the archived feeds. 🤦Should be fixed in this commit: https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
Jenny has to look for the metadata fields, it must find the
# prev = ... line. To do so, I naively wrote something along these lines:
for line in content.splitlines():
if line.startswith('# prev = '):
...
Problem is, we use \u2028 a lot in twtxt feeds and Python interprets those as line separators as well. That’s not what we want here. Jenny must only split at a
\n.Now @prologic had a quote/copy of some of his metadata fields in a twt. Like so:
# prev = foo bar
Perfectly legitimate, but now jenny found the
# prev = *twice* (once in the actual header, once in a twt), didn’t know what to do, and thus did not fetch the archived feeds. 🤦Should be fixed in this commit: https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
Jenny has to look for the metadata fields, it must find the
# prev = ... line. To do so, I naively wrote something along these lines:
for line in content.splitlines():
if line.startswith('# prev = '):
...
Problem is, we use \\u2028 a lot in twtxt feeds and Python interprets those as line separators as well. That’s not what we want here. Jenny must only split at a
\\n.Now @prologic had a quote/copy of some of his metadata fields in a twt. Like so:
# prev = foo bar
Perfectly legitimate, but now jenny found the
# prev = *twice* (once in the actual header, once in a twt), didn’t know what to do, and thus did not fetch the archived feeds. 🤦Should be fixed in this commit: https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
But yes, this has a nice discoverability bonus. And even simpler than a hash, that's right.