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.

ErikASD creates XMR payment processor that uses PGP login system
ErikASD1 has created simpyle-xmr-processor 2 - a Python-based concept Monero payment processor that credits accounts using a PGP login system:

I was interested on which the best way to accept XMR programmatically and made this concept payment processor that credits PGP based accounts with the XMR amount deposited like an exchange would have with sub addresses assigned to each account.3

To h … ⌘ Read more

Monero Tech meeting scheduled for 21 October 2024 1800 UTC
The next Monero Tech meeting is scheduled to take place on Monday, October 21 2024 at 18:00 UTC, in the #no-wallet-left-behind 1 IRC-Libera/Matrix channels:

Based on the opinions given here2 I decided to go back to the No Wallet Left Behind Matrix room and IRC channel for the next i.e. coming Monday’s meeting, and to not contiune to hold meetings like the last one in the -dev Matrix room and IRC channel.

This meeting’s chai … ⌘ Read more

[ANN] If you run the haveno.markets website, please contact me

[..] Do you operate haveno.markets? You are welcome to stay pseudoanonymous but please open source the project and start accepting contributions from the community (like me). Two updates I can think of right away are to include a json api and to source data from bisq too. Please contact me at www.ki9.us/contact if you know anything about haveno.markets or its operator. If I don’t hear back after a week or two, I will have to assume haveno.markets is untrustworthy until pro … ⌘ Read more

Erlang Solutions: Why Open Source Technologies is a Smart Choice for Fintech Businesses
Traditionally, the fintech industry relied on proprietary software, with usage and distribution restricted by paid licences. Fintech open-source technologies were distrusted due to security concerns over visible code in complex systems.

But fast-forward to today and financial institutions, including neobanks like Revolut and Monzo, have embraced open source solutions. … ⌘ Read more

[LFF] Monero meetup group in Barcelona (Spain)

Hello I am running the Monero meetup group in Barcelona (Spain) and looking for support to organize a in-person event before end of the year. The idea is to spread the word in the city about XMR what it is and why privacy is important. I am aiming for a more social networking environment to gather privacy enthusiasts but open to sugestions. I would like to ask here if you guys could help with some funds to rent a space if needed.

Link: [https://www.meetup.com/es-ES/monero-meetup-barcel … ⌘ Read more

[WTS] [US] [$95] ThinkPad T560

ThinkPad T560 - i7-6600U @ 2.60GHz - 8GB DDR3 RAM - 256GB SSD. Pop_OS! is installed, but I can put whatever distro you’d like. I can also load the Monero Blockchain on it if you wish. Comes with charger.

Link: https://xmrbazaar.com/listing/gHpx/

xmrRedux (XMRBazaar) ⌘ Read more

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”`

Hetzner has Object Storage in beta now. I got access to it, but one thing is holding me back from using it: A fixed price (5,95 € per month per bucket), even if there is nothing stored in there or way less than the included 1 TB. Why not bill based on actual usage, like most other services are doing it nowadays? I guess I will keep using Scaleway Object Storage and Cloudflare R2. ⌘ Read more

Highlights from Git 2.47
Git 2.47 is here, with features like incremental multi-pack indexes and more. Check out our coverage of some of the highlights here.

The post Highlights from Git 2.47 appeared first on The GitHub Blog. ⌘ Read more

I think salty.im is simplest than simplex. But attempt to implement this i have problems than salty cli cant decrypt messages from another saltpack realization (and reverse) . Also simplex is more decentralized (like nostr?)

Monero Tech meeting scheduled for 14 October 2024 1800 UTC
The next Monero Tech meeting is scheduled to take place on Monday, October 14 2024 at 18:00 UTC, in the #no-wallet-left-behind 1 IRC-Libera/Matrix channels:

Based on the opinions given here2 I decided to go back to the No Wallet Left Behind Matrix room and IRC channel for the next i.e. coming Monday’s meeting, and to not contiune to hold meetings like the last one in the -dev Matrix room and IRC channel.

This meeting’s chai … ⌘ Read more

Same! Great joke!

i like this one

I share I did write up an algorithm for it at some point I think it is lost in a git comment someplace. I’ll put together a pseudo/go code this week.

Super simple:

Making a reply:

1. If yarn has one use that. (Maybe do collision check?)
   
2. Make hash of twt raw no truncation.
   
3. Check local cache for shortest without collision
   
   • in SQL: select len(subject) where head_full_hash like subject || '%'
     

Threading:

1. Get full hash of head twt
   
2. Search for twts
   
   • in SQL: head_full_hash like subject || '%' and created_on > head_timestamp
     

The assumption being replies will be for the most recent head. If replying to an older one it will use a longer hash.

Lol, this is actually a good thing by Apple. Doesn’t kill social apps at all, just prevents some harvesting of your entire address book by abusive apps like WhatsApp.

I mean sure if i want to run it over on my tooth brush why not use something that is accessible everywhere like md5? crc32? It was chosen a long while back and the only benefit in changing now is “i cant find an implementation for x” when the down side is it breaks all existing threads. so…

Turning legacy to leverage: building developer platforms in brownfield environments
Member post originally published on the Syntasso blog by Cat Morris While building an internal developer platform sounds like something an engineering organisation would do – and often tries to do – from scratch, the reality is, most… ⌘ Read more

It has twts cache which used if timeline is set to jew. Maybe i.should fork twet to make wishes like newlines (i see two squares), showing conversations, showing twts if not found in cache and parsing medata to configure url, nick and followers (currenly it duplicated in config and twtxt file)

Yes, im also do not like Hugo so rewrite theme above to Jekyll (with some changes)

@prologic@twtxt.net YES James, it should be up to the client to deal with changes like edits and deletions. And putting this load on the clients, location-addressing with make this a lot easier since what is says it: Look in this file at this timestamp, did anything change or went missing? (And then threading will not break;)

JMP: SMS Censorship
Since almost the very beginning of JMP there have been occasional SMS and MMS delivery failures with an error message like “Rejected for SPAM”. By itself this is not too surprising, since every communications system has a SPAM problem and every SPAM blocking technique has some false positives. Over the past few years, however, the incidence of this error has gone up and up. But whenever we investigate, we find no SPAM being sent, just regular humans having regular conversations. So what is happening here? Are … ⌘ Read more

@prologic@twtxt.net

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

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.

iOS 18 Features You Should Use
By now it’s fairly likely you have either heard about or updated to iOS 18 on iPhone or iPadOS 18 on iPad, and you might be wondering about some of the new features. While there are some major new features along with many small changes and mini features here and there, there are a handful … Read More ⌘ Read more

I’d like to see them fine me 2% of zero dollars

(#2024-09-24T12:45:54Z) @prologic@twtxt.net I’m not really buying this one about readability. It’s easy to recognize that this is a URL and a date, so you skim over it like you would we mentions and markdown links and images. If you are not suppose to read the raw file, then we might a well jam everything into JSON like mastodon

lol, this flags looks like russian name

Some more arguments for a local-based treading model over a content-based one:

1. The format: (#<DATE URL>) or (@<DATE URL>) both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash) and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.

2. Having something like (#<DATE URL>) will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash. This will also make it possible to make 3th part twt-mentions services.

3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don’t follow.

x86 Embedded Controller with PC/104 Compatibility for Legacy Systems
The VDX3-6757 PC/104 family of low-power x86 embedded controllers meets PC/104 specifications, offering backward compatibility for projects facing end-of-life x86-based controllers. It is suited for applications like data acquisition, industrial automation, process control, and automotive control. Powered by a DM&P Vortex86DX3 1GHz dual-core CPU with 32KB L1 cache and 512KB L2 cache, the VDX3-6757 supports … ⌘ Read more

5th Beta of iOS 18.1, MacOS Sequoia 15.1, iPadOS 18.1 with Apple Intelligence, Available for Testing
Apple has released the 5th beta versions of iOS 18.1, macOS Sequoia 15.1, and iPadOS 18.1, with Apple Intelligence support. The Apple Intelligence features that are included with these releases are mostly Writing Tools, summaries, and new Siri features, which allow you to do things like summarize emails, offer Smart Replies in Mail and Mes … ⌘ Read more

@movq@www.uninformativ.de Yes, the tools are surprisingly fast. Still, magrep takes about 20 seconds to search through my archive of 140K emails, so to speed things up I would probably combine it with an indexer like mu, mairix or notmuch.

@bender@twtxt.net

Sorry, you’re right, I should have used numbers!

I’m don’t understand what “preserve the original hash” could mean other than “make sure there’s still a twt in the feed with that hash”. Maybe the text could be clarified somehow.

I’m also not sure what you mean by markdown already being part of it. Of course people can already use Markdown, just like presumably nothing stopped people from using (twt subjects) before they were formally described. But it’s not universal; e.g. as a jenny user I just see the plain text.

@prologic@twtxt.net Do you feel the same about published vs. privately stored data?

For me there’s a distinction. I feel very strongly that I should be able to retain whatever private information I like. On the other hand, I do have some sympathy for requests not to publish or propagate (though I personally feel it’s still morally acceptable to ignore such requests).

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

@david@collantes.us Thanks, that’s good feedback to have. I wonder to what extent this already exists in registry servers and yarn pods. I haven’t really tried digging into the past in either one.

How interested would you be in changes in metadata and other comments in the feeds? I’m thinking of just permanently saving every version of each twtxt file that gets pulled, not just the twts. It wouldn’t be hard to do (though presenting the information in a sensible way is another matter). Compression should make storage a non-issue unless someone does something weird with their feed like shuffle the comments around every time I fetch it.

@movq@www.uninformativ.de I don’t think it has to be like that. Just make sure the new version of the twt is always appended to your current feed, and have some convention for indicating it’s an edit and which twt it supersedes. Keep the original twt as-is (or delete it if you don’t want new followers to see it); doesn’t matter if it’s archived because you aren’t changing that copy.

Kubecon + CloudNativeCon North America 2024 co-located event deep dive: Data on Kubernetes Day
Co-chairs: Melissa Logan and Adam DurrNovember 12, 2024Salt Lake City, Utah Organizations like Etsy, Grab, Dish Network, and Chick-fil-A have standardized on Kubernetes and shared best practices for running different types of stateful workloads. Our aim for the… ⌘ Read more

@prologic@twtxt.net Do you have a link to some past discussion?

Would the GDPR would apply to a one-person client like jenny? I seriously hope not. If someone asks me to delete an email they sent me, I don’t think I have to honour that request, no matter how European they are.

I am really bothered by the idea that someone could force me to delete my private, personal record of my interactions with them. Would I have to delete my journal entries about them too if they asked?

Maybe a public-facing client like yarnd needs to consider this, but that also bothers me. I was actually thinking about making an Internet Archive style twtxt archiver, letting you explore past twts, including long-dead feeds, see edit histories, deleted twts, etc.

I wrote some code to try out non-hash reply subjects formatted as (replyto ), while keeping the ability to use the existing hash style.

I don’t think we need to decide all at once. If clients add support for a new method then people can use it if they like. The downside of course is that this costs developer time, so I decided to invest a few hours of my own time into a proof of concept.

With apologies to @movq@www.uninformativ.de for corrupting jenny’s beautiful code. I don’t write this expecting you to incorporate the patch, because it does complicate things and might not be a direction you want to go in. But if you like any part of this approach feel free to use bits of it; I release the patch under jenny’s current LICENCE.

Supporting both kinds of reply in jenny was complicated because each email can only have one Message-Id, and because it’s possible the target twt will not be seen until after the twt referencing it. The following patch uses an sqlite database to keep track of known (url, timestamp) pairs, as well as a separate table of (url, timestamp) pairs that haven’t been seen yet but are wanted. When one of those “wanted” twts is finally seen, the mail file gets rewritten to include the appropriate In-Reply-To header.

Patch based on jenny commit 73a5ea81.

https://www.falsifian.org/a/oDtr/patch0.txt

Not implemented:

• Composing twts using the (replyto …) format.
  
• Probably other important things I’m forgetting.

Oh. looks like its 4 chars. git show 64bf

i feel like we should isolate a subset of markdown that makes sense and built it into lextwt. it already has support for links and images. maybe basic formatting bold, italic. possibly block quote and bullet lists. no tables or footnotes

@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 Agreed that hashes have a benefit. I came up with a similar example where when I twted about an 11-character hash collision. Perhaps hashes could be made optional somehow. Like, you could use the “replyto” idea and then additionally put a hash somewhere if you want to lock in which version of the twt you are replying to.

@movq@www.uninformativ.de ooooh, nice! commit 62a2b7735749f2ff3c9306dd984ad28f853595c5:

Crawl archived feeds in –fetch-context

Like, very much! :-)

@quark@ferengi.one I don’t really mind if the twt gets edited before I even fetch it. I think it’s the idea of my computer discarding old versions it’s fetched, especially if it’s shown them to me, that bugs me.

But I do like @movq@www.uninformativ.de’s suggestion on this thread that feeds could contain both the original and the edited twt. I guess it would be up to the author.

@quark@ferengi.one None. I like being able to see edit history for the same reason.

@prologic@twtxt.net I wouldn’t want my client to honour delete requests. I like my computer’s memory to be better than mine, not worse, so it would bug me if I remember seeing something and my computer can’t find it.

@prologic@twtxt.net

There’s a simple reason all the current hashes end in a or q: the hash is 256 bits, the base32 encoding chops that into groups of 5 bits, and 256 isn’t divisible by 5. The last character of the base32 encoding just has that left-over single bit (256 mod 5 = 1).

So I agree with #3 below, but do you have a source for #1, #2 or #4? I would expect any lack of variability in any part of a hash function’s output would make it more vulnerable to attacks, so designers of hash functions would want to make the whole output vary as much as possible.

Other than the divisible-by-5 thing, my current intuition is it doesn’t matter what part you take.

1. Hash Structure: Hashes are typically designed so that their outputs have specific statistical properties. The first few characters often have more entropy or variability, meaning they are less likely to have patterns. The last characters may not maintain this randomness, especially if the encoding method has a tendency to produce less varied endings.

2. Collision Resistance: When using hashes, the goal is to minimize the risk of collisions (different inputs producing the same output). By using the first few characters, you leverage the full distribution of the hash. The last characters may not distribute in the same way, potentially increasing the likelihood of collisions.

3. Encoding Characteristics: Base32 encoding has a specific structure and padding that might influence the last characters more than the first. If the data being hashed is similar, the last characters may be more similar across different hashes.

4. Use Cases: In many applications (like generating unique identifiers), the beginning of the hash is often the most informative and varied. Relying on the end might reduce the uniqueness of generated identifiers, especially if a prefix has a specific context or meaning.

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