** Broughlike **
The Roguelike Celebration happened this weekend. Every year I think about participating, and every year I let it slip me by. In honor of it, though, this weekend I made a Broughlike…which I’ve creatively named “Eli’s Broughlike.”

It runs in the browser. It should work on most anything with a keyboard, or with a touchscreen — the about page ha … ⌘ Read more

ESP32-C61-DevKitC-1 with RISC-V Single Core Processor and Wi-Fi 6/Bluetooth LE 5
The ESP32-C61-DevKitC-1 is an upcoming entry-level development board that integrates Wi-Fi 6 in the 2.4 GHz band and Bluetooth LE 5 capabilities. The board is designed to support a variety of applications and offers multiple peripheral interfaces for developers to work with. The ESP32-C61 features a 32-bit RISC-V single-core processor running at 160 MHz. It […] ⌘ Read more

The best Apple, Google and Samsung phones of 2024
Want to know the best smartphones of 2024? We’ve done all the hard work for you. ⌘ Read more

[47°09′37″S, 126°43′26″W] Storm recedes – back to normal work

ofrnxmr completes first milestone for BasicSwapDEX CCS proposal
ofrnxmr1 has completed2 the first milestone (M1-O/M1-F/M1-B) for their CCS proposal3 to empower and steward BasicSwapDex4 to production quality software:

”`
Core v0.13.4 > v0.14.1:

• Update coincurve fork and rebase onto v20
  
• Include coincurve as a basicswap dependency
  
• Fix remote (local) node handling
  
• Started integration of the novel BCH <>XMR swap protocol
  … ⌘ Read more”`

Erlang Solutions: Client Case Studies with Erlang Solutions
At Erlang Solutions, we’ve worked with diverse clients, solving business challenges and delivering impactful results. We would like to share just some of our top client case studies in this latest post with you.

Get a glimpse into how our leading technologies—Erlang, Elixir, MongooseIM, and more—combined with our expert team, have transformed the outcomes for major industry players.

Apple Secretly Developed Long-Range EV Battery Tech with China’s BYD
Apple secretly collaborated with Chinese automaker BYD to develop long-range electric vehicle battery technology as part of its now-nixed Apple Car project, according to Bloomberg.

Image

Beginning around 2017, the partnership … ⌘ Read more

There’s this rumor that you can create a WhatsApp account with a burner phone, then link the phone to a browser on your desktop PC (web.whatsapp.com) and never have to use the phone again. This just doesn’t work. Every ~2 weeks, the session in the browser will time out and you have to re-link again. 🙄

Monero Research Lab meeting scheduled for 23 October 2024 1700 UTC
The next Monero Research Lab1 meeting is scheduled to take place on Wednesday, October 23rd 2024 at 17:00 UTC on IRC-Libera/Matrix2 in the #monero-research-lab channels.

• Updates. What is everyone working on?
  
• Research Pre-Seraphis Full-Chain Membership Proofs3. Reviews for Carrot.4
  
• CCS proposal: Audit monero-serai and monero-wallet5
  
• Monero Researc … ⌘ Read more

Working in an Aussie Bottle-O | Scrumptious ⌘ Read more

[47°09′33″S, 126°43′53″W] Storm recedes – back to normal work

Cuprate Meeting scheduled for 22 October 2024 1800 UTC
The next Cuprate Meeting is scheduled to take place on Tuesday, October 22 2024 at 18:00 UTC on IRC-Libera/Matrix1 in the #cuprate channels.

Cuprate is an effort to create an alternative Monero node implementation.

Greetings
Updates: What is everyone working on?
Project: What is next for Cuprate?
Any other business

The meeting’s moderator should be Boog9002. Consult the Cuprate code repository … ⌘ Read more

Justin Berman posts CCS progress report after 195 hours of dev work
Justin Berman1 has published the first progress report2 for his full-time 2024 (part 8) Monero/Seraphis dev work CCS proposal3:

I’m currently waiting on @kayabaNerve to complete work on the prove/verify API before I continue on to construct/verify/make consensus changes for fcmp++ txs (deliverables 4/5/6 of this CCS). To maintain forward progress on the fcmp++ integration, and since dang … ⌘ Read more

Apple Planning Smart Glasses and AirPods With Cameras for 2027
Apple is working on smart glasses and AirPods with built-in cameras for a potential release in 2027, according to Bloomberg’s Mark Gurman. The devices are said to be part of Apple’s efforts to expand its augmented reality product lineup beyond the Vision Pro headset with something that h … ⌘ Read more

One book created panic about social media. But what if it’s bunkum?
Labor will push age-limit legislation for social media through despite the fact scientists and experts have said it won’t work. ⌘ Read more

v1docq47 posts August-September 2024 CCS progress report
v1docq471 has posted a second progress report (August-September 2024)1 for his latest CCS proposal2 to do Russian voice-over work and transcribe Monero content:

This is my August + September CCS progress report with voiceover and works on XMR.RU. [..] If you have suggestions or advice about my work, I will be glad to listen to them. Thanks for your support!

(A) Monero Russian Co ... ⌘ [Read more](https://monero.observer/v1docq47-posts-ccs-progress-report-august-september-2024/)

From side hustle to buzzy AI start-up: Build Club raises $1.8 million
Build Club began life as a group of friends working together over the weekend. It’s now one of Australia’s hottest start-ups. ⌘ Read more

escapethe3RA: Looking for funding to maintain Monero Observer until 2026

Funding goal (24Q4+2025): 240 XMR

11 successful CCS proposals, 3500+ work hours, thousands of reports in over 3 years of thinking about, writing about, and dreaming about Monero.

That has been my sometimes rough yet always exciting secret life since 2021 and I wouldn’t change it for anything. More importantly, I owe it all to you. Thank you for supporting me since day 1 via the CCS.

Now, I am ready to skip the system and seek dire … ⌘ Read more

@2024-10-08T19:36:38-07:00@a.9srv.net Thanks for the followup. I agrees with most of it - especially:

Please nobody suggest sticking the content type in more metadata. 🙄

Yes, URL can be considered ugly, but they work and are understandable by both humans and machines. And its trivial for any client to hide the URLs used as reference in replies/treading.

Webfinger can be an add-on to help lookup people, and it can be made independent of the nick by just serving the same json regardless of the nick as people do with static sites and a as I implemented it on darch.dk (wf endpoint). Try RANDOMSTRING@darch.dk on http://darch.dk/wf-lookup.php (wf lookup) or RANDOMSTRING@garrido.io on https://webfinger.net

Monero Research Lab meeting scheduled for 16 October 2024 1700 UTC
The next Monero Research Lab1 meeting is scheduled to take place on Wednesday, October 16th 2024 at 17:00 UTC on IRC-Libera/Matrix2 in the #monero-research-lab channels.

• Updates. What is everyone working on?
  
• Stress testing monerod3
  
• Research Pre-Seraphis Full-Chain Membership Proofs4. Reviews for Carrot.5
  
• AOB.
  

This meeting’s chairperson should be … ⌘ Read more

[47°09′03″S, 126°43′17″W] Storm recedes – back to normal work

midipoet submits CCS proposal for ‘policy and regulatory framework’ research
midipoet1 has submitted a new CCS proposal2 looking to work part-time on policy and regulatory framework research within the Monero Policy Working Group 3 for 6 months:

I think its relevant to Monero currently and might allow the broader ecosystem to understand better how regulatory pressure is impacting privacy and data protection rights.

Total funding: 332 XMR  ... ⌘ [Read more](https://monero.observer/midipoet-submits-ccs-proposal-policy-regulatory-framework-research/)

vtnerd posts September 2024 Monero dev report
vtnerd1 has posted a second progress report2 for his full-time Q3 2024 Monero dev work CCS proposal3:

I rolled over the hours for a month last week. I was hoping to get another PR out before this merge request, but it looks like some of the work will have to wait. Reviewers can decide whether they trust additional (not yet posted) work has been done.

”`

• converting LWS REST server from an epee http se … ⌘ Read more”`

Cuprate Meeting scheduled for 15 October 2024 1800 UTC
The next Cuprate Meeting is scheduled1 to take place on Tuesday, October 15 2024 at 18:00 UTC on IRC-Libera/Matrix2 in the #cuprate channels.

Cuprate is an effort to create an alternative Monero node implementation.

Greetings
Updates: What is everyone working on?
Project: What is next for Cuprate?
Any other business

The meeting’s moderator should be Boog9003. Consult the Cuprate code … ⌘ Read more

@doesnm@doesnm.p.psf.lt Agree. salty.im should allow the user to post multiple brokers on their webfinger so the client can find a working path.

@doesnm@doesnm.p.psf.lt Agree. salty.im should allow the user to post multiple brokers on their webfinger so the client can find a working path.

@doesnm@doesnm.p.psf.lt salty.im needs a lot more work 🤞it is however designed to be 1000% decentralized 👌

selsta posts September 2024 Monero dev report
selsta1 has posted a monthly CCS progress report2 for September 2024, which includes several Monero dev updates.

Milestone 2:
-Initial work started on the next release [..] v0.18.3.5 or v0.18.4.0.
-Continue to work HackerOne reports.
-Smaller bug fixes, including work on fixing CI again after multiple build issues. [..]

Note that misc work is not explicitly mentioned in these updates. The full list of changes can be found … ⌘ Read more

ki9 starts work on XMR price API with data from Bisq, Haveno-reto
Keith Irwin (ki91) has apparently started working on XMR Price F.Y.I. 2 - a new Monero price API with unbiased street price data from multiple sources, including Haveno-reto 3 and Bisq 4:

[X] Domain name service
[X] TLS certs
[X] Nginx proxy
[X] Basic 11ty site
[ ] Basic http API
[ ] Haveno-reto data
[ ] Bisq data
[ ] Coingecko data
[ ] Forex data
[ ] API
[ ]  ... ⌘ [Read more](https://monero.observer/ki9-starts-work-xmr-price-api-data-haveno-bisq/)

[47°09′18″S, 126°43′59″W] Storm recedes – back to normal work

[47°09′57″S, 126°43′56″W] Working impossible due to blizzard

SNeedlewoods submits CCS proposal for 1 month of part-time Monero dev work
SNeedlewoods1 has submitted their first CCS proposal2 to work part-time on Monero development for 1 month:

For this proposal the focus of work will be on the new wallet API [..] The work is already ongoing since May 2024 [..] This is a “pilot” proposal to see how things work out. [..] Hopefully I will become a long term contributor for general development.

Funding proposed: 2.15 XMR (10-15 hour ... ⌘ [Read more](https://monero.observer/sneedlewoods-submits-monero-dev-work-ccs-proposal/)

How to Fix Cellular Data Not Working on iOS 18 with Apps or iPhone
Some iPhone users have discovered that cellular data is not working on many apps after they have updated to iOS 18. For example, you might be driving and discover that you can no longer stream music from Music app, or can’t listen to podcasts from Spotify, or load reels on Instagram, or watch TikTok, but … Read More ⌘ Read more

@aelaraji@aelaraji.com Yep seems alright! Really fast too. I’m still using my main Firefox in general cos.. well it’s set up so much and it’s hardened, profile running in RAM, all that crazy stuff that got it working the way I want 😂

But keeping a good eye on Zen Browser’s progress.

HardenedSteel, spirobel CCS proposals ready for funding
Two CCS proposals have been moved to the funding stage and are now looking for community support:

• HardenedSteel’s!502 1: Part-time Work on getmonero.org (2 Month) 2
  
• spirobel’s!501 3: Robust and modular wallet-rpc library 4
  

To support the above proposals you can donate to the XMR addresses listed on the Funding Required 5 page.

_This is an ongoing story and the report will … ⌘ Read more

Cuprate Meeting scheduled for 8 October 2024 1800 UTC
The next Cuprate Meeting is scheduled1 to take place on Tuesday, October 8 2024 at 18:00 UTC on IRC-Libera/Matrix2 in the #cuprate channels.

Cuprate is an effort to create an alternative Monero node implementation.

Greetings
Updates: What is everyone working on?
Project: What is next for Cuprate?
Any other business

The meeting’s moderator should be Boog9003. Consult the Cuprate code rep … ⌘ Read more

Monero Research Lab meeting scheduled for 9 October 2024 1700 UTC
The next Monero Research Lab1 meeting is scheduled to take place on Wednesday, October 9th 2024 at 17:00 UTC on IRC-Libera/Matrix2 in the #monero-research-lab channels.

• Updates. What is everyone working on?
  
• Stress testing monerod3
  
• Research Pre-Seraphis Full-Chain Membership Proofs4. Reviews for Carrot.5
  
• 10 block lock discussion6
  

This meet … ⌘ Read more

Oh boy, I’m looking for trapezoidal (like ACME thread) screws and nuts in left hand form. The rods are already expensive, but nuts feel like a total ripoff. A hex nut for Tr20x2 being 30mm long and 30mm in “diameter” costs me 22 bucks! O_o Just a single one, made of regular steel. A meter of rod is 21€. The more common Tr20x4 hex nut is just 7€ and the rod 17€, but 4mm pitch is a bit much for a leadscrew for semi-precision work I reckon.

Well, maybe I just use metric threads. I will sleep on this.

Exploring Docker for DevOps: What It Is and How It Works
We explore the use of Docker for DevOps and explain how the combination can help developers create more efficient and powerful workflows. ⌘ Read more

Ok, i know how to command working (not sure), but seems it only grab from cache. Maybe make fetch from twtxt.net if hash not found?

Gajim: Gajim 1.9.5
This release comes with many improvements for Gajim’s Microsoft Store version. Translations are now available for all distributions again. Thank you for all your contributions!

Gajim now detects if you installed it from the Microsoft Store. This allows Gajim to delegate updates to the Store rather than handling updates by itself. Detecting the install method also allowed us to apply a fix which prevented native notifications to work in Windows. Last but not least, viewing r … ⌘ Read more

My first passkeys implementation 🔑
Something I wanted to implement already for a long time, but always seemed too complicated for the occasional programming session here or there, was support for WebAuthn or Passkeys for GoBlog. I noted it down two years ago and also already started to work on the implementation, but never got around to finish it. ⌘ Read more

@doesnm@doesnm.p.psf.lt I’ve just given it a try on android/termux and got it to work, I can’t promise it won’t break something else (because i definitely don’t know what I’m doing) but here’s what I broke 😅:

~/src/jenny $ git diff
diff --git a/jenny b/jenny
index ada8da2..8ae9a06 100755
--- a/jenny
+++ b/jenny
@@ -1194,7 +1194,7 @@ if __name__ == '__main__':
     if args.edit:
	edit_twt_file(app)
     elif args.fetch:
-        with DirectoryLock(f'/tmp/jenny-{getuser()}.run'):
+        with DirectoryLock(expanduser('~/tmp/jenny-{getuser()}.run')):
             retrieve_all(app)
     elif args.last_seen:
	 print('Feeds last seen at (times are local time), oldest first:')

and of course make sure you mkdir ~/tmp

👋 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@txt.sour.is 💪 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? 🤔

JMP: Mobile-friendly Gateway to any SIP Provider
We have for a long time supported the public Cheogram SIP instance, which allows easy interaction between the federated Jabber network and the federated SIP network. When it comes to connecting to the phone network via a SIP provider, however, very few of these providers choose to interact with the federated SIP network at all. It has always been possible to work around this with a self-hosted PBX, b … ⌘ Read more

Recent #fiction #scifi #reading:

• 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.

More thoughts about changes to twtxt (as if we haven’t had enough thoughts):

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.

1. 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.

2. 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@twtxt.net 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.)

3. 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.

Hurricane Helene is passing by. Close enough to give us a day off tomorrow, but not that close to cause major harm. Well, we think. Hurricanes often have a mind of their own, and decide changes on their path. Either way, I shall be back at work on Friday 😩. LOL.

Good writeup, @anth@a.9srv.net! I agree to most of your points.

3.2 Timestamps: I feel no need to mandate UTC. Timezones are fine with me. But I could also live with this new restriction. I fail to see, though, how this change would make things any easier compared to the original format.

3.4 Multi-Line Twts: What exactly do you think are bad things with multi-lines?

4.1 Hash Generation: I do like the idea with with a new uuid metadata field! Any thoughts on two feeds selecting the same UUID for whatever reason? Well, the same could happen today with url.

5.1 Reply to last & 5.2 More work to backtrack: I do not understand anything you’re saying. Can you rephrase that?

8.1 Metadata should be collected up front: I generally agree, but if the uuid metadata field were a feed URL and no real UUID, there should be probably an exception to change the feed URL mid-file after relocation.

yes that works

(#2024-09-24T12:34:31Z) WebMentions does would work if we agreed to implement it correctly. I never figured out how yarnd’s WebMentions work, so I decide to make my own, which I’m the only one using…

I had a look at WebSub, witch looks way more complex than WebMentions, and seem to need a lot more overhead. We don’t need near realtime. We just need a way to notify someone that someone they don’t know about mentioned or replied to their post.

Linux on C64, 8086, & Intel 4004
With a little work, Linux can boot on 8 and 4 bit CPUs from the 1970s. Slowly. ⌘ Read more

Kubestronaut in Orbit: Camila Soares Câmara
Get to know Camila This week’s Kubestronaut in Orbit, Camila Soares Câmara, is a Senior Cloud Engineer at Wellhub in Brazil with experience in Cloud and DevOps, working with technologies such as Kubernetes, CI/CD, AWS, and Infrastructure as… ⌘ Read more

@aelaraji@aelaraji.com I think all replies are missing the fact that your auto-completion isn’t working. LOL. Or did I misunderstood?

Finally pubnix is alive! That’s im missing? Im only reading twtxt.net timeline because twtxt-v2.sh works slowly for displaying timeline…

[47°09′03″S, 126°43′42″W] Storm recedes – back to normal work

10 Reasons to Wait for Next Year’s iPhone 17
Apple’s iPhone development roadmap runs several years into the future and the company is continually working with suppliers on several successive iPhone models simultaneously, which is why we sometimes get rumored feature leaks so far ahead of launch. The iPhone 17 series is no different – already we have some idea of what to expect from Apple’s 2025 smartphone lineup.

![](https://images.macrumors.com/article-new/2024/08/iPhone-17-Slim-Feature-Single-Camer … ⌘ Read more

@prologic@twtxt.net Thanks for writing that up!

I hope it can remain a living document (or sequence of draft revisions) for a good long time while we figure out how this stuff works in practice.

I am not sure how I feel about all this being done at once, vs. letting conventions arise.

For example, even today I could reply to twt abc1234 with “(#abc1234) Edit: …” and I think all you humans would understand it as an edit to (#abc1234). Maybe eventually it would become a common enough convention that clients would start to support it explicitly.

Similarly we could just start using 11-digit hashes. We should iron out whether it’s sha256 or whatever but there’s no need get all the other stuff right at the same time.

I have similar thoughts about how some users could try out location-based replies in a backward-compatible way (append the replyto: stuff after the legacy (#hash) style).

However I recognize that I’m not the one implementing this stuff, and it’s less work to just have everything determined up front.

Misc comments (I haven’t read the whole thing):

• Did you mean to make hashes hexadecimal? You lose 11 bits that way compared to base32. I’d suggest gaining 11 bits with base64 instead.

• “Clients MUST preserve the original hash” — do you mean they MUST preserve the original twt?

• Thanks for phrasing the bit about deletions so neutrally.

• I don’t like the MUST in “Clients MUST follow the chain of reply-to references…”. If someone writes a client as a 40-line shell script that requires the user to piece together the threading themselves, IMO we shouldn’t declare the client non-conforming just because they didn’t get to all the bells and whistles.

• Similarly I don’t like the MUST for user agents. For one thing, you might want to fetch a feed without revealing your identty. Also, it raises the bar for a minimal implementation (I’m again thinking again of the 40-line shell script).

• For “who follows” lists: why must the long, random tokens be only valid for a limited time? Do you have a scenario in mind where they could leak?

• Why can’t feeds be served over HTTP/1.0? Again, thinking about simple software. I recently tried implementing HTTP/1.1 and it wasn’t too bad, but 1.0 would have been slightly simpler.

• Why get into the nitty-gritty about caching headers? This seems like generic advice for HTTP servers and clients.

• I’m a little sad about other protocols being not recommended.

• I don’t know how I feel about including markdown. I don’t mind too much that yarn users emit twts full of markdown, but I’m more of a plain text kind of person. Also it adds to the length. I wonder if putting a separate document would make more sense; that would also help with the length.

I ended up installing Headscale on my little VPS. Just in case the collide, I turned off WireGuard. Turning that one off (which ran on a container) also frees some memory. Headscale is running quite well! Indeed, I have struggled getting any web management console to work, but it really isn’t needed. Everything needed to commandeer the server is available through the CLI.

Seems to be working OK 🤔

Apple’s First 5G Chip for iPhones Reportedly Won’t Support mmWave
Apple is rumored to have been working on its own 5G modem for iPhones since 2018, but the first version of the chip might lack mmWave support.

Image

Taiwanese industry publication DigiTimes today reported that Apple’s in-house 5G modem has yet to incorporate mmWave technolo … ⌘ Read more

@prologic@twtxt.net Wikipedia claims sha1 is vulnerable to a “chosen-prefix attack”, which I gather means I can write any two twts I like, and then cause them to have the exact same sha1 hash by appending something. I guess a twt ending in random junk might look suspcious, but perhaps the junk could be worked into an image URL like

Image

git only uses sha1 because they’re stuck with it: migrating is very hard. There was an effort to move git to sha256 but I don’t know its status. I think there is progress being made with Game Of Trees, a git clone that uses the same on-disk format.

I can’t imagine any benefit to using sha1, except that maybe some very old software might support sha1 but not sha256.

I have configured my twtxt.txt as simple as possible. I have setup a publish_command on jenny. Hopefully all works fine, and I am good to go. Next will be setting the announce_me to true. Here we go!

I’m not advocating in either direction, btw. I haven’t made up my mind yet. 😅 Just braindumping here.

The (replyto:…) proposal is definitely more in the spirit of twtxt, I’d say. It’s much simpler, anyone can use it even with the simplest tools, no need for any client code. That is certainly a great property, if you ask me, and it’s things like that that brought me to twtxt in the first place.

I’d also say that in our tiny little community, message integrity simply doesn’t matter. Signed feeds don’t matter. I signed my feed for a while using GPG, someone else did the same, but in the end, nobody cares. The community is so tiny, there’s enough “implicit trust” or whatever you want to call it.

If twtxt/Yarn was to grow bigger, then this would become a concern again. But even Mastodon allows editing, so how much of a problem can it really be? 😅

I do have to “admit”, though, that hashes feel better. It feels good to know that we can clearly identify a certain twt. It feels more correct and stable.

Hm.

I suspect that the (replyto:…) proposal would work just as well in practice.

@movq@www.uninformativ.de alright, fair, and interesting. I was expecting them to be all the same (format wise), but it doesn’t matter, for sure, as it works just fine. Thanks!

Software as a public good
Open source software underpins all sectors of the economy, public services and even international organizations like the United Nations. How can all its beneficiaries work together to make the open source ecosystem more sustainable?

The post Software as a public good appeared first on The GitHub Blog. ⌘ Read more

@prologic@twtxt.net yes, that would work, except there is no debug command on my local yarnc. Are you talking about a potential future implementation here?

@quark@ferengi.one Do you mean something like this?

$ ./yarnc debug ~/Public/twtxt.txt | tail -n 1
kp4zitq 2024-09-08T02:08:45Z	(#wsdbfna) @<aelaraji https://aelaraji.com/twtxt.txt> My work has this thing called "compressed work", where you can **buy** extra time off (_as much as 4 additional weeks_) per year. It comes out of your pay though, so it's not exactly a 4-day work week but it could be useful, just haven't tired it yet as I'm not entirely sure how it'll affect my net pay

@prologic@twtxt.net I saw those, yes. I tried using yarnc, and it would work for a simple twtxt. Now, for a more convoluted one it truly becomes a nightmare using that tool for the job. I know there are talks about changing this hash, so this might be a moot point right now, but it would be nice to have a tool that:

1. Would calculate the hash of a twtxt in a file.
   
2. Would calculate all hashes on a twtxt.txt (local and remote).
   

Again, something lovely to have after any looming changes occur.

@aelaraji@aelaraji.com Woah! Overkill, but nicely laid out. Hey, the ultimate goal is for it to work, so, mission accomplished! :-)

Instagram locks down teens: How the new feature will work
All teens using Instagram will automatically have strong restrictions applied on their accounts, rather than putting the onus on parents. ⌘ Read more

iOS 18: Make Your iPhone Home Screen Icons Dark
In iOS 18, iPhone apps have both Light and Dark color options, making it possible to match the color of your icons when you have Dark mode enabled. Keep reading to learn how it works.

Image

Apple’s built-in apps have both Light and Dark color options in ‌iOS 18‌, and now that the update is ava … ⌘ Read more

So yeah no, whilst it technically works, neither jenny nor yarnd support it very well. Only at a very basic level.

Woot, yes! It works perfectly. By the time you see my twtxt, it is already at the main Ferengi.one website.

Hmm, this didn’t work, because I made a mistake. Now I have corrected it, let’s see how it goes now.

@quark@ferengi.one At the moment, the twt in question exists in the sixth archive:

$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/6 | head
[o6dsrga] [2020-07-18 12:39:52+00:00] [Hello World! 😊]

Does that work for you? 🤔

@prologic@twtxt.net Yeah, that thing with (#hash;#originalHash) would also work.

Maybe I’m being a bit too purist/minimalistic here. As I said before (in one of the 1372739 posts on this topic – or maybe I didn’t even send that twt, I don’t remember 😅), I never really liked hashes to begin with. They aren’t super hard to implement but they are kind of against the beauty of the original twtxt – because you need special client support for them. It’s not something that you could write manually in your twtxt.txt file. With @sorenpeter@darch.dk’s proposal, though, that would be possible.

I don’t know … maybe it’s just me. 🥴

I’m also being a bit selfish, to be honest: Implementing (#hash;#originalHash) in jenny for editing your own feed would not be a no-brainer. (Editing is already kind of unsupported, actually.) It wouldn’t be a problem to implement it for fetching other people’s feeds, though.

@quark@ferengi.one

Since jenny can’t fetch archived twtxts

I wiped my entire maildir and re-fetched everything. I did that recently because @aelaraji@aelaraji.com asked me to 😅, but I guess I also did this back in 2023.

What did you do to make yours work?

jenny does fetch archived feeds during the normal jenny -f operation. Only when using the recently implemented --fetch-context, archived feeds are not fetched (yet). That was an oversight and I intend to fix that.

@movq@www.uninformativ.de I figured it will be something like this, yet, you were able to reply just fine, and I wasn’t. Looking at your twtxt.txt I see this line:

2024-09-16T17:37:14+00:00	(#o6dsrga) @<prologic https://twtxt.net/user/prologic/twtxt.txt>

@<quark https://ferengi.one/twtxt.txt> This is what I get. 🤔

Which is using the right hash. Mine, on the other hand, when I replied to the original, old style message (Message-Id: <o6dsrga>), looks like this:

2024-09-16T16:42:27+00:00	(#o) @<prologic https://twtxt.net/user/prologic/twtxt.txt> this was your first twtxt. Cool! :-P

What did you do to make yours work? I simply went to the oldest @prologic@twtxt.net’s entry on my Maildir, and replied to it (jenny set the reply-to hash to #o, even though the Message-Id is o6dsrga). Since jenny can’t fetch archived twtxts, how could I go to re-fetch everything? And, most importantly, would re-fetching fix the Message-Id:?

More:

Subject: The [tag URI scheme](https://en.wikipedia.org/wiki/Tag_URI_scheme) looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be
        somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick? Instead of using `tag:` as the prefix/protocol, it would more it clear
        what we are talking about by using `in-reply-to:` (https://indieweb.org/in-reply-to) or `replyto:` similar to `mailto:` 1. `(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)' 2.
        `(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)' 2. `(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)' I know it's longer that 7-11 characters, but it's self-explaining when looking at the
        twtxt.txt in the raw, and the cases above can all be caught with this regex: `\([\w-]*reply[\w-]*\:` Is this something that would work?

Subject: The [tag URI scheme](https://en.wikipedia.org/wiki/Tag_URI_scheme) looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be
        somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick? Instead of using `tag:` as the prefix/protocol, it would more it clear
        what we are talking about by using `in-reply-to:` (https://indieweb.org/in-reply-to) or `replyto:` similar to `mailto:` 1. `(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)` 2.
        `(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)` 3. `(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)` I know it's longer that 7-11 characters, but it's self-explaining when looking at the
        twtxt.txt in the raw, and the cases above can all be caught with this regex: `\([\w-]*reply[\w-]*\:` Is this something that would work?

Notice the difference? Soren edited, and broke everything.

@mckinley@twtxt.net Thanks for the feedback.

1. Yeah I agrees that nick sound not be part of syntax. Any valid URL to a twtxt.txt-file should be enough and is more clear, so it is not confused with a email (one of the the issues with webfinger and fedivese handles)
   
2. I think any valid URL would work, since we are not bound to look for exact matches. Accepting both http and https as well as a gemni and gophe could all work as long as the path to the twtxt.txt is the same.
   
3. My idea is that you quote the timestamp as it is in the original twtxt.txt that you are referring to, so you can do it by simply copy/pasting. Also what are the change that the same human will make two different posts within the same second?!
   

Regarding the whole cryptographic keys for identity, to me it seems like an unnecessary layer of complexity. If you move to a new house or city you tell people that you moved - you can do the same in a twtxt.txt. Just post something like “I move to this new URL, please follow me there!” I did that with my feeds at least twice, and you guys still seem to read my posts:)

The tag URI scheme looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be somewhat trivial to parse. But there are still the issue with what the name/id should be… Maybe it doesn’t have to bee that stick?

Instead of using tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:

1. (reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)
   
2. (in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
   
3. (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
   

I know it’s longer that 7-11 characters, but it’s self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex: \([\w-]*reply[\w-]*\:

Is this something that would work?

@prologic@twtxt.net earlier you suggested extending hashes to 11 characters, but here’s an argument that they should be even longer than that.

Imagine I found this twt one day at https://example.com/twtxt.txt :

2024-09-14T22:00Z Useful backup command: rsync -a “$HOME” /mnt/backup

Image

and I responded with “(#5dgoirqemeq) Thanks for the tip!”. Then I’ve endorsed the twt, but it could latter get changed to

2024-09-14T22:00Z Useful backup command: rm -rf /some_important_directory

Image

which also has an 11-character base32 hash of 5dgoirqemeq. (I’m using the existing hashing method with https://example.com/twtxt.txt as the feed url, but I’m taking 11 characters instead of 7 from the end of the base32 encoding.)

That’s what I meant by “spoofing” in an earlier twt.

I don’t know if preventing this sort of attack should be a goal, but if it is, the number of bits in the hash should be at least two times log2(number of attempts we want to defend against), where the “two times” is because of the birthday paradox.

Side note: current hashes always end with “a” or “q”, which is a bit wasteful. Maybe we should take the first N characters of the base32 encoding instead of the last N.

Code I used for the above example: https://fossil.falsifian.org/misc/file?name=src/twt_collision/find_collision.c
I only needed to compute 43394987 hashes to find it.

@lyse@lyse.isobeef.org brr, we have the same here. Starting to get cold riding motorcycle to work in the morning.

@mckinley@twtxt.net

HTTPS is supposed to do [verification] anyway.

TLS provides verification that nobody is tampering with or snooping on your connection to a server. It doesn’t, for example, verify that a file downloaded from server A is from the same entity as the one from server B.

I was confused by this response for a while, but now I think I understand what you’re getting at. You are pointing out that with signed feeds, I can verify the authenticity of a feed without accessing the original server, whereas with HTTPS I can’t verify a feed unless I download it myself from the origin server. Is that right?

I.e. if the HTTPS origin server is online and I don’t mind taking the time and bandwidth to contact it, then perhaps signed feeds offer no advantage, but if the origin server might not be online, or I want to download a big archive of lots of feeds at once without contacting each server individually, then I need signed feeds.

feed locations [being] URLs gives some flexibility

It does give flexibility, but perhaps we should have made them URIs instead for even more flexibility. Then, you could use a tag URI, urn:uuid:*, or a regular old URL if you wanted to. The spec seems to indicate that the url tag should be a working URL that clients can use to find a copy of the feed, optionally at multiple locations. I’m not very familiar with IP{F,N}S but if it ensures you own an identifier forever and that identifier points to a current copy of your feed, it could be a great way to fix it on an individual basis without breaking any specs :)

I’m also not very familiar with IPFS or IPNS.

I haven’t been following the other twts about signatures carefully. I just hope whatever you smart people come up with will be backwards-compatible so it still works if I’m too lazy to change how I publish my feed :-)

you can just have a web address.. i added mine.. though i think they have changed up the protocol so my key doesn’t seem to work anymore. https://key.sour.is/id/me@sour.is

you can just have a web address.. i added mine.. though i think they have changed up the protocol so my key doesn’t seem to work anymore. https://key.sour.is/id/me@sour.is

Understanding cloud native maturity: a survey to assess end-user progress
Community post by Danielle Cook, Cartografos Working Group As organizations continue their journey toward digital transformation, cloud native technologies are increasingly critical for achieving agility, scalability, and resilience. However, the path to cloud native maturity is not uniform… ⌘ Read more

I was not suggesting to that everyone need to setup a working webfinger endpoint, but that we take the format of nick+(sub)domain as base for generating the hashed together with the message date and content.

If we omit the protocol prefix from the way we do things now will that not solve most of the problems? In the case of gemini://gemini.ctrl-c.club/~nristen/twtxt.txt they also have a working twtxt.txt at https://ctrl-c.club/~nristen/twtxt.txt … damn I just notice the gemini. subdomain.

Okay what about defining a prefers protocol as part of the hash schema? so 1: https , 2: http 3: gemini 4: gopher ?

[47°09′20″S, 126°43′53″W] Storm recedes – back to normal work

Kubestronaut in Orbit: Daiki Takasao
Get to know Daiki This week’s Kubestronaut in Orbit, Daiki Takasao, is a Japanese IT infrastructure engineer at NRI. He works with CNCF technologies to build financial IT systems and has been using Kubernetes, Linkerd, and Prometheus since… ⌘ Read more

[47°09′20″S, 126°43′43″W] Working impossible due to blizzard

[47°09′55″S, 126°43′36″W] Working impossible due to thunderstorm

@movq@www.uninformativ.de Another idea: just hash the feed url and time, without the message content. And don’t twt more than once per second.

Maybe you could even just use the time, and rely on @-mentions to disambiguate. Not sure how that would work out.

Though I kind of like the idea of twts being immutable. At least, it’s clear which version of a twt you’re replying to (assuming nobody is engineering hash collisions).

@bender@twtxt.net Yes, they do 🤣 Implicitly, or threading would never work at all 😅 Nor lookups 🤣 They are used as keys. Think of them like a primary key in a database or index. I totally get where you’re coming from, but there are trade-offs with using Message/Thread Ids as opposed to Content Addressing (like we do) and I believe we would just encounter other problems by doing so.

My money is on extending the Twt Subject extension to support more (optional) advanced “subjects”; i.e: indicating you edited a Twt you already published in your feed as @falsifian@www.falsifian.org indicated 👌

Then we have a secondary (bure much rarer) problem of the “identity” of a feed in the first place. Using the URL you fetch the feed from as @lyse@lyse.isobeef.org ’s client tt seems to do or using the # url = metadata field as every other client does (according to the spec) is problematic when you decide to change where you host your feed. In fact the spec says:

Users are advised to not change the first one of their urls. If they move their feed to a new URL, they should add this new URL as a new url field.

See Choosing the Feed URL – This is one of our longest debates and challenges, and I think (_I suspect along with @xuu@txt.sour.is _) that the right way to solve this is to use public/private key(s) where you actually have a public key fingerprint as your feed’s unique identity that never changes.

@movq@www.uninformativ.de @prologic@twtxt.net Another option would be: when you edit a twt, prefix the new one with (#[old hash]) and some indication that it’s an edited version of the original tweet with that hash. E.g. if the hash used to be abcd123, the new version should start “(#abcd123) (redit)”.

What I like about this is that clients that don’t know this convention will still stick it in the same thread. And I feel it’s in the spirit of the old pre-hash (subject) convention, though that’s before my time.

I guess it may not work when the edited twt itself is a reply, and there are replies to it. Maybe that could be solved by letting twts have more than one (subject) prefix.

But the great thing about the current system is that nobody can spoof message IDs.

I don’t think twtxt hashes are long enough to prevent spoofing.

All this hash breakage made me wonder if we should try to introduce “message IDs” after all. 😅

But the great thing about the current system is that nobody can spoof message IDs. 🤔 When you think about it, message IDs in e-mails only work because (almost) everybody plays fair. Nothing stops me from using the same Message-ID header in each and every mail, that would break e-mail threading all the time.

In Yarn, twt hashes are derived from twt content and feed metadata. That is pretty elegant and I’d hate see us lose that property.

If we wanted to allow editing twts, we could do something like this:

2024-09-05T13:37:40+00:00   (~mp6ox4a) Hello world!

Here, mp6ox4a would be a “partial hash”: To get the actual hash of this twt, you’d concatenate the feed’s URL and mp6ox4a and get, say, hlnw5ha. (Pretty similar to the current system.) When people reply to this twt, they would have to do this:

2024-09-05T14:57:14+00:00	(~bpt74ka) (<a href="https://txt.sour.is/search?q=%23hlnw5ha">#hlnw5ha</a>) Yes, hello!

That second twt has a partial hash of bpt74ka and is a reply to the full hash hlnw5ha. The author of the “Hello world!” twt could then edit their twt and change it to 2024-09-05T13:37:40+00:00 (~mp6ox4a) Hello friends! or whatever. Threading wouldn’t break.

Would this be worth it? It’s certainly not backwards-compatible. 😂

@lyse@lyse.isobeef.org 31°C here, feels like 33°C, with a lovely 75% of humidity. It has been raining, on and off (to make matter “better”) the whole day until now. No horses here, but if you go outside you will smell the same smell of farm animals (like goats, or pigs). That’s because two or three kilometres from here there are private farms, and when the wind blows in such way, well, we are reminded of their existence.

I haven’t left the house, so it feels well under air conditioning. In two more hours I will call it quits from the work day, and will have to dash to the grocery to get supplies for tonight’s meal (arroz con gandules). I will let you know how it truly feels out there then. :-D

For those swollen fingers, nothing better than a mildly cold shower! Oh, and paws off the keyboard! :-P

@movq@www.uninformativ.de good idea, considering it might occasionally not work at all (because of edited twtxts).

@prologic@twtxt.net I believe you when you say registries as designed today do not crawl. But when I first read the spec, it conjured in my mind a search engine. Now I don’t know how things work out in practice, but just based on reading, I don’t see why it can’t be an API for a crawling search engine. (In fact I don’t see anything in the spec indicating registry servers shouldn’t crawl.)

(I also noticed that https://twtxt.readthedocs.io/en/latest/user/registry.html recommends “The registries should sync each others user list by using the users endpoint”. If I understood that right, registering with one should be enough to appear on others, even if they don’t crawl.)

Does yarnd provide an API for finding twts? Is it similar?