πŸ‘‹ Thanks for joining us on our Sept monthly Yarn.social meetup today y’all πŸ™‡β€β™‚οΈ We had @david@collantes.us @sorenpeter@darch.dk @doesnm@doesnm.p.psf.lt @falsifian@www.falsifian.org and @xuu πŸ’ͺ Nice turn out! (not all at once of course, as we normally run this over 4 hours as we span many time zones!)

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@darch.dk write some PHP to process/parse User-Agent and service his feed via a custom PHP script πŸ˜…
  • @falsifian@www.falsifian.org introduced himself πŸ‘Œ
  • Talked about Merkle Trees 🌳

Did I miss anything? πŸ€”

​ Read More

@movq@www.uninformativ.de Yes! Basically @david@collantes.us points out that if we mandate that authors should retain the original timestamp in their feed when adjusting content, making fixes, etc, that they retain the original timestamp and leave it unaltered. We already do this anyway, we just need to say so.

Now we have a situation where folks participating in a β€œconversation” (thread) with appropriate clients can automatically detect edits with almost 100% accuracy by mere fact that the next time they fetch a feed that contains an edit, they now see two versions of the Twt with two different hashes, but identical timestamps.

You can use the fetch time to approximate a β€œversion number” and deal with the display (UX) appropriately.

I can’t believe I didn’t think of this before πŸ€¦β€β™‚οΈ

​ Read More

Personally I don’t see it as a problem. I didn’t even really see edits as a problem either tbh, but this is just an incremental improvement I think.

​ Read More

Participate

Login to join in on this yarn.