Things we talked about:
- Decentralised vs. Distributed
- Use of SHA256 for Twt Hash(es)
- We solved Edits! 🥳
- UUID(s) probably won't work! (_susceptible to sppofing_)
- Helped @sorenpeter write some PHP to process/parse
User-Agent and service his feed via a custom PHP script 😅- @falsifian introduced himself 👌
- Talked about Merkle Trees 🌳
Did I miss anything? 🤔
Things we talked about:
- Decentralised vs. Distributed
- Use of SHA256 for Twt Hash(es)
- We solved Edits! 🥳
- UUID(s) probably won't work! (_susceptible to sppofing_)
- Helped @sorenpeter write some PHP to process/parse
User-Agent and service his feed via a custom PHP script 😅- @falsifian introduced himself 👌
- Talked about Merkle Trees 🌳
Did I miss anything? 🤔
yarnd and WebSub 
yarnd and WebSub
- @lyse and @sorenpeter express simplicity. Both Lyse and Sorenpeter support location-based addressing.
- @falsifian believes we should continue to develop ideas and extensions progressively over time like we've always done.
- @david @quark and @bender would like a better user experience, especially when threads break due to edits, deletions or feed location changes.
- @anth would like to see utf-8 mandated, and the threading model remain largely the same as it is today, which is primarily based on the convention of a Twt Subject anyway, Twt Hash(es) just make the threading "more precise". Anth also states that format, client and server specification/recommendations should be kept separate.
- @movq @xuu sorry you two haven't said too much really, so I'm not too sure?
Overall, the 22 votes we've had on the poll from the community (_if you can call it a community?_) have clearly shown that:
- We continue to support content-based addressing. (65/35)
- We think about formally supporting edits/deletes (60/40)
- We do not increase the use of cryptography (_thworing things like authenticity and identity out the window_) (70/30)
And overall the NPS (_net promoter score_) of "Would I recommend Twtxt to a friend" is a whopping 7/10 (_which is crazy! 🤯_)
Let's have our monthly catch up soon™ (1hr) and discuss together. My own take on the direction we should take at this point is as follows:
- We continue to use hashing for the threading model.
- We think about changing this to SHA-256 for simplicity.
- We either adopt @anth's UUID approach or @lyse Dynamic URL approach.
- We continue to incrementally/progressively improve things over time as @falsifian suggested.
- We think about mandating utf-8 as @anth suggests which makes things so much easier for everyone.
- We further discuss the merits/ideas of supporting formal Edit/Delete requests or other ways to better support this in some way.
- @lyse and @sorenpeter express simplicity. Both Lyse and Sorenpeter support location-based addressing.
- @falsifian believes we should continue to develop ideas and extensions progressively over time like we've always done.
- @david @quark and @bender would like a better user experience, especially when threads break due to edits, deletions or feed location changes.
- @anth would like to see utf-8 mandated, and the threading model remain largely the same as it is today, which is primarily based on the convention of a Twt Subject anyway, Twt Hash(es) just make the threading "more precise". Anth also states that format, client and server specification/recommendations should be kept separate.
- @movq @xuu sorry you two haven't said too much really, so I'm not too sure?
Overall, the 22 votes we've had on the poll from the community (_if you can call it a community?_) have clearly shown that:
- We continue to support content-based addressing. (65/35)
- We think about formally supporting edits/deletes (60/40)
- We do not increase the use of cryptography (_thworing things like authenticity and identity out the window_) (70/30)
And overall the NPS (_net promoter score_) of "Would I recommend Twtxt to a friend" is a whopping 7/10 (_which is crazy! 🤯_)
Let's have our monthly catch up soon™ (1hr) and discuss together. My own take on the direction we should take at this point is as follows:
- We continue to use hashing for the threading model.
- We think about changing this to SHA-256 for simplicity.
- We either adopt @anth's UUID approach or @lyse Dynamic URL approach.
- We continue to incrementally/progressively improve things over time as @falsifian suggested.
- We think about mandating utf-8 as @anth suggests which makes things so much easier for everyone.
- We further discuss the merits/ideas of supporting formal Edit/Delete requests or other ways to better support this in some way.
- 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"? 🤔
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.
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
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
# 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 🤣~
What has the poor guy done? 🤣
What has the poor guy done? 🤣
james at mills dot io? 🤔
james at mills dot io? 🤔
yarnd. If there was any poorly worded "things", it was just merely pointing out lacking capabilities for caching and discovery.
yarnd. If there was any poorly worded "things", it was just merely pointing out lacking capabilities for caching and discovery.
> You can take IRC out of my cold 🥶 dead 😵 hands 🙌
> You can take IRC out of my cold 🥶 dead 😵 hands 🙌
james instead 🤣
james instead 🤣
$ inspect-db yarns.db | jq -r '.Value.URL' | grep 'aelaraji.com'
https://aelaraji.com/test_feed.txt
https://aelaraji.com/twtxt.txt
$ inspect-db yarns.db | jq -r '.Value.URL' | grep 'aelaraji.com'
https://aelaraji.com/test_feed.txt
https://aelaraji.com/twtxt.txt
kex1fhxntuc0av7q48hlfj970ve297dzzghn82wp5cahr9r92y8rlrqqtwp983
kex1fhxntuc0av7q48hlfj970ve297dzzghn82wp5cahr9r92y8rlrqqtwp983