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.

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/)

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.

It’s time to fertilise your spring veggies. Here’s what works best
Spring has sprung and now is the best time to fertilise many food plants. So, what do you need to know and what should you feed your veggie patch or pots? ⌘ Read more

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

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

today I wrote a CV sequencer in VoodooAssembly for work O__O #coding #programming #embedded

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.

Reward work ⌘ Read more

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

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

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

Seems to be working OK 🤔

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

@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?

@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

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.

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

@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

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 ?

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

@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).

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