- Authenticity
- Integrity
- Precision
The last one involves _actually_ supporting the notion of "Edits" and "Deletes" IMO more formally. Without this it would be quite hard to support a strong/good UX. Another way to think about this is "Versioned Twts".
- Authenticity
- Integrity
-
The last one involves _actually_ supporting the notion of "Edits" and "Deletes" IMO more formally. Without this it would be quite hard to support a strong/good UX. Another way to think about this is "Versioned Twts".
- Authenticity
- Integrity
-
The last one involves _actually_ supporting the notion of "Edits" and "Deletes" IMO more formally. Without this it would be quite hard to support a strong/good UX. Another way to think about this is "Versioned Twts".
> Digitally Sign Twts: Each Twt could be digitally signed using a private key associated with the UUID. The signature would be calculated over the concatenation of the UUID, timestamp, and content. The public key could be published along with the feed so anyone can verify the authenticity of the Twt by checking the signature. This approach ensures that only the true owner of the UUID (and the corresponding private key) can produce valid hashes.
Which leads us to more Cryptography. Something which y'all voted against.
> Digitally Sign Twts: Each Twt could be digitally signed using a private key associated with the UUID. The signature would be calculated over the concatenation of the UUID, timestamp, and content. The public key could be published along with the feed so anyone can verify the authenticity of the Twt by checking the signature. This approach ensures that only the true owner of the UUID (and the corresponding private key) can produce valid hashes.
Which leads us to more Cryptography. Something which y'all voted against.
- A
/twtxt.txt.sig (_detached signauture_)- Or a way to sign the
# uuid = with a key that can be verified.Hmmm and as I write this actually, I _think_ this doesn't work either, because you can still just copy it regardless. Hmmm @xuu help me out here? How do we prevent "spoofing"? 🤔
- A
/twtxt.txt.sig (_detached signauture_)- Or a way to sign the
# uuid = with a key that can be verified.Hmmm and as I write this actually, I _think_ this doesn't work either, because you can still just copy it regardless. Hmmm @xuu help me out here? How do we prevent "spoofing"? 🤔
Just a bunch of shell commands I can pipe together to search, list, view and reply to email (after syncing it to a local Maildir).
EXAMPLES at https://git.vuxu.org/mblaze/tree/README
So far I'm using most of the tools directly from the command line, but I might take inspiration from https://sr.ht/~rakoo/omail/ to make my workflow a bit more efficient.
*To get any closer, I think I'd have to hand-craft my own SMTP client or something.
It's for this reason I'd like to try changing the Twt Hash extension to use SHA-256 which is a far more common tool available pretty much everywhere. I _think_ the effort involved in "precise threading" (_using content addressing_) becomes much easier to "author" (_note that participating in an existing thread has always been trivial, just copy the Twt Subject in your Twt_).
It's for this reason I'd like to try changing the Twt Hash extension to use SHA-256 which is a far more common tool available pretty much everywhere. I _think_ the effort involved in "precise threading" (_using content addressing_) becomes much easier to "author" (_note that participating in an existing thread has always been trivial, just copy the Twt Subject in your Twt_).
I argue you do. It's nice to have a "@nick@domain
It's also quite nice to have a visual representation of the feed too. description can be optional.
Without this, feeds are a bit too "bland" IMO.
I argue you do. It's nice to have a "@nick@domain
It's also quite nice to have a visual representation of the feed too. description can be optional.
Without this, feeds are a bit too "bland" IMO.
> but IMO that shouldn’t be done at the same time as introducing new untested ideas
> but IMO that shouldn’t be done at the same time as introducing new untested ideas
This is why we need "authenticity" 🤣 Yes if you copied my feed's UUID, then you'd end up generating identical hashes to me if we posted at identical times with identical timestamps. Not good 😌
> Also, was the dot after the timestamp intended?
No, sorry.
This is why we need "authenticity" 🤣 Yes if you copied my feed's UUID, then you'd end up generating identical hashes to me if we posted at identical times with identical timestamps. Not good 😌
> Also, was the dot after the timestamp intended?
No, sorry.
> See https://dev.twtxt.net
Yes, that is exactly what I meant. I like that collection and "twtxt v2" feels like a departure.
Maybe there's an advantage to grouping it into one spec, but IMO that shouldn't be done at the same time as introducing new untested ideas.
> See https://yarn.social (especially this section: https://yarn.social/#self-host) -- It really doesn't get much simpler than this 🤣
Again, I like this existing simplicity. (I would even argue you don't need the metadata.)
That page says "For the best experience your client should also support some of the Twtxt Extensions..." but it is clear you don't need to. I would like it to stay that way, and publishing a big long spec and calling it "twtxt v2" feels like a departure from that. (I think the content of the document is valuable; I'm just carping about how it's being presented.)
cat <<EOF
# nick = $USER
# avatar = https://example.com/$USER.png
# description = Hi 👋 I'm Bob!
# uuid = 7E9BC039-4969-4296-9920-4BACDBA8ED5C
2024-09-28T11:19:25+10:00 Hello World!
EOF > ~/public_html/twtxt.txt
And:
- Serve your file with
Content-type: text/plain; charset=utf-8
cat <<EOF
# nick = $USER
# avatar = https://example.com/$USER.png
# description = Hi 👋 I'm Bob!
# uuid = 7E9BC039-4969-4296-9920-4BACDBA8ED5C
2024-09-28T11:19:25+10:00. Hello World!
EOF > ~/public_html/twtxt.txt
And:
- Serve your file with
Content-type: text/plain; charset=utf-8
cat <<EOF
# nick = $USER
# avatar = https://example.com/$USER.png
# description = Hi 👋 I'm Bob!
# uuid = 7E9BC039-4969-4296-9920-4BACDBA8ED5C
2024-09-28T11:19:25+10:00 Hello World!
EOF > ~/public_html/twtxt.txt
And:
- Serve your file with
Content-type: text/plain; charset=utf-8
- The Memory Police by Yōko Ogawa. Lovely writing. Very understated; reminded me of Kazuo Ishiguro. Sort of like Nineteen Eighty-Four but not. (I first heard it recommended in comparison to that work.)
- Subcutanean by Aaron Reed; https://subcutanean.textories.com/ . Every copy of the book is different, which is a cool idea. I read two of them (one from the library, actually not different from the other printed copies, and one personalized e-book). I don't read much horror so managed to be a little creeped out by it, which was fun.
- The Wind from Nowhere, a 1962 novel by J. G. Ballard. A random pick from the sci-fi section; I think I picked it up because it made me imagine some weird 4-dimensional effect ("from nowhere" meaning not in a normal direction) but actually (spoiler) it was just about a lot of wind for no reason. The book was moderately entertaining but there was nothing special about it.
Currently reading Scale by Greg Egan and Inversion by Aric McBay.
See https://yarn.social (especially this section: https://yarn.social/#self-host) -- It really doesn't get much simpler than this 🤣
See https://yarn.social (especially this section: https://yarn.social/#self-host) -- It really doesn't get much simpler than this 🤣
> There are lots of great ideas here! Is there a benefit to putting them all into one document? Seems to me this could more easily be a bunch of separate efforts that can progress at their own pace:
See https://dev.twtxt.net
> There are lots of great ideas here! Is there a benefit to putting them all into one document? Seems to me this could more easily be a bunch of separate efforts that can progress at their own pace:
See https://dev.twtxt.net
1. There are lots of great ideas here! Is there a benefit to putting them all into one document? Seems to me this could more easily be a bunch of separate efforts that can progress at their own pace:
1a. Better and longer hashes.
1b. New possibly-controversial ideas like edit: and delete: and location-based references as an alternative to hashes.
1c. Best practices, e.g. Content-Type: text/plain; charset=utf-8
1d. Stuff already described at dev.twtxt.net that doesn't need any changes.
2. We won't know what will and won't work until we try them. So I'm inclined to think of this as a bunch of draft ideas. Maybe later when we've seen it play out it could make sense to define a group of recommended twtxt extensions and give them a name.
3. Another reason for 1 (above) is: I like the current situation where all you need to get started is these two short and simple documents:
\thttps://twtxt.readthedocs.io/en/latest/user/twtxtfile.html
\thttps://twtxt.readthedocs.io/en/latest/user/discoverability.html
and everything else is an extension for anyone interested. (Deprecating non-UTC times seems reasonable to me, though.) Having a big long "twtxt v2" document seems less inviting to people looking for something simple. (@prologic you mentioned an anonymous comment "you've ruined twtxt" and while I don't completely agree with that commenter's sentiment, I would feel like twtxt had lost something if it moved away from having a super-simple core.)
4. All that being said, these are just my opinions, and I'm not doing the work of writing software or drafting proposals. Maybe I will at some point, but until then, if you're actually implementing things, you're in charge of what you decide to make, and I'm grateful for the work.=
1. There are lots of great ideas here! Is there a benefit to putting them all into one document? Seems to me this could more easily be a bunch of separate efforts that can progress at their own pace:
1a. Better and longer hashes.
1b. New possibly-controversial ideas like edit: and delete: and location-based references as an alternative to hashes.
1c. Best practices, e.g. Content-Type: text/plain; charset=utf-8
1d. Stuff already described at dev.twtxt.net that doesn't need any changes.
2. We won't know what will and won't work until we try them. So I'm inclined to think of this as a bunch of draft ideas. Maybe later when we've seen it play out it could make sense to define a group of recommended twtxt extensions and give them a name.
3. Another reason for 1 (above) is: I like the current situation where all you need to get started is these two short and simple documents:
https://twtxt.readthedocs.io/en/latest/user/twtxtfile.html
https://twtxt.readthedocs.io/en/latest/user/discoverability.html
and everything else is an extension for anyone interested. (Deprecating non-UTC times seems reasonable to me, though.) Having a big long "twtxt v2" document seems less inviting to people looking for something simple. (@prologic you mentioned an anonymous comment "you've ruined twtxt" and while I don't completely agree with that commenter's sentiment, I would feel like twtxt had lost something if it moved away from having a super-simple core.)
4. All that being said, these are just my opinions, and I'm not doing the work of writing software or drafting proposals. Maybe I will at some point, but until then, if you're actually implementing things, you're in charge of what you decide to make, and I'm grateful for the work.=
# uuid = (_if present_) otherwise just falling back to the URL you fetched it from and dropping the idea of a feed # url = entirely.
# uuid = (_if present_) otherwise just falling back to the URL you fetched it from and dropping the idea of a feed # url = entirely.
- ~65/35 in favor of Content Addressing
- ~60/40 in favor of supporting Edit/Delete
- ~70/30 against more cryptograph
And an NPS score of 7/10 🤣~
- ~65/35 in favor of Content Addressing
- ~60/40 in favor of supporting Edit/Delete
- ~70/30 against more cryptograph
And an NPS score of 7/10 🤣~
>
> (#sbmynna) @xuu wrote:
>
> > "@bender I am also in camp no edit signals. deletes only breaks the head of a thread. all the replies are unaffected."
>
> I figure I could also answer *every* single twtxt like this, so that if the original gets edited, or deleted, at least I don't sound foolish without knowing exactly what I replied to. 🤭
It Sounds like a good idea! should that be limited to just direct replays or can it be extended to
replays to other replays, that way and With just the right amount of chain-replays, we'll be RRrrrrrevolutionizing the way people Mailing Lists like, in no time! xD P.S: Just a reminder! I've already told you not to mind my twts for the next couple of hours, right!
>
> (#sbmynna) @xuu wrote:
>
> > "@bender I am also in camp no edit signals. deletes only breaks the head of a thread. all the replies are unaffected."
>
> I figure I could also answer *every* single twtxt like this, so that if the original gets edited, or deleted, at least I don't sound foolish without knowing exactly what I replied to. 🤭
It Sounds like a good idea! should that be limited to just direct replays or can it be extended to
replays to other replays, that way and With just the right amount of chain-replays, we'll be RRrrrrrevolutionizing the way people Mailing Lists like, in no time! xD P.S: Just a reminder! I've already told you not to mind my twts for the next couple of hours, right!
>
> (#sbmynna) @xuu wrote:
>
> > "@bender I am also in camp no edit signals. deletes only breaks the head of a thread. all the replies are unaffected."
>
> I figure I could also answer *every* single twtxt like this, so that if the original gets edited, or deleted, at least I don't sound foolish without knowing exactly what I replied to. 🤭
It Sounds like a good idea! should that be limited to just direct replays or can it be extended to
replays to other replays, that way and With just the right amount of chain-replays, we'll be RRrrrrrevolutionizing the way people Mailing Lists like, in no time! xD P.S: Just a reminder! I've already told you not to mind my twts for the next couple of hours, right!
> "@bender I am also in camp no edit signals. deletes only breaks the head of a thread. all the replies are unaffected."
I figure I could also answer *every* single twtxt like this, so that if the original gets edited, or deleted, at least I don't sound foolish without knowing exactly what I replied to. 🤭
Meta fined $102 million for storing passwords in plain text
Meta fined $102 million for storing passwords in plain text