Ignite Realtime Blog: Florian, Dan and Dave Elected in the XSF!
In an annual vote, not one, not two, but three Ignite Realtime community members have been selected into leadership positions of the XMPP Standards Foundation!

Image

The XMPP Standards Foundation is an independent, nonprofit standards development organisation whose [primary mission is to define open protocols](https://xmpp.org … ⌘ Read more

iSG Display Max Gateway for Smart Home Automation with Matter and Zigbee
AmeriDroid recently featured the iSG Display Max Gateway, a flexible platform designed to streamline smart home management and automation. With its 10-inch display and support for Wi-Fi and Bluetooth Low Energy, the gateway integrates multiple protocols to offer flexibility for diverse smart home setups. The device is powered by an eight-core processor, although specific details […] ⌘ Read more

(#bq5blta) @bender@bender Just because you can run it doesn’t make it decentralised. As @doesnm rightfully points out, where are the points o …
@bender Just because you can run it doesn’t make it decentralised. As @doesnm @doesnm.p.psf.lt rightfully points out, where are the points of controls? It’s a distributed network with a protocol that forms a “network”. With key services operated by BlueSky this isn’t decentrali … ⌘ Read more

The XMPP Standards Foundation: MongooseIM 6.3 - Monitor with Prometheus, scale up with CockroachDB
MongooseIM is a scalable, efficient, high-performance instant messaging server. At Erlang Solutions, we believe that it is essential to use the right tool for the job, and this is why the server implements the proven, open, and extensible XMPP protocol, which was designed for instant messaging from the beginnning. Thanks … ⌘ Read more

Erlang Solutions: MongooseIM 6.3: Prometheus, CockroachDB and more
MongooseIM is a scalable, efficient, high-performance instant messaging server using the proven, open, and extensible XMPP protocol. With each new version, we introduce new features and improvements. For example, version 6.2.0 introduced our new CETS in-memory storage, making setup and autoscaling in cloud environments easier than before (see the blog post for … ⌘ Read more

@eapl.me@eapl.me here are my replies (somewhat similar to Lyse’s and James’)

1. Metadata in twts: Key=value is too complicated for non-hackers and hard to write by hand. So if there is a need then we should just use #NSFS or the alt-text file in markdown image syntax ![NSFW](url.to/image.jpg) if something is NSFW

2. IDs besides datetime. When you edit a twt then you should preserve the datetime if location-based addressing should have any advantages over content-based addressing. If you change the timestamp the its a new post. Just like any other blog cms.

3. Caching, Yes all good ideas, but that is more a task for the clients not the serving of the twtxt.txt files.

4. Discovery: User-agent for discovery can become better. I’m working on a wrapper script in PHP, so you don’t need to go to Apaches log-files to see who fetches your feed. But for other Gemini and gopher you need to relay on something else. That could be using my webmentions for twtxt suggestion, or simply defining an email metadata field for letting a person know you follow their feed. Interesting read about why WebMetions might be a bad idea. Twtxt being much simple that a full featured IndieWeb sites, then a lot of the concerns does not apply here. But that’s the issue with any open inbox. This is hard to solve without some form of (centralized or community) spam moderation.

5. Support more protocols besides http/s. Yes why not, if we can make clients that merge or diffident between the same feed server by multiples URLs

6. Languages: If the need is big then make a separate feed. I don’t mind seeing stuff in other langues as it is low. You got translating tool if you need to know whats going on. And again when there is a need for easier switching between posting to several feeds, then it’s about building clients with a UI that makes it easy. No something that should takes up space in the format/protocol.

7. Emojis: I’m not sure what this is about. Do you want to use emojis as avatar in CLI clients or it just about rendering emojis?

Forlinx FET MX95xx C System on Module for Industrial and IoT Applications
Forlinx Embedded has introduced the FET-MX95xx-C System on Module, built around the high-performance NXP i.MX95xx processor for industrial, automotive, and IoT applications. Key features include a 10GbE port, dual GbE ports, CAN interfaces, camera support, and multiple wireless protocols. Unlike the FET3562J-C SoM, this new Forlinx device is powered by the NXP i.MX95xx processor. It […] ⌘ Read more

Righto, @eapl.me@eapl.me, ta for the writeup. Here we go. :-)

Metadata on individual twts are too much for me. I do like the simplicity of the current spec. But I understand where you’re coming from.

Numbering twts in a feed is basically the attempt of generating message IDs. It’s an interesting idea, but I reckon it is not even needed. I’d simply use location based addressing (feed URL + ‘#’ + timestamp) instead of content addressing. If one really wanted to, one could hash the feed URL and timestamp, but the raw form would actually improve disoverability and would not even require a richer client. But the majority of twtxt users in the last poll wanted to stick with content addressing.

yarnd actually sends If-Modified-Since request headers. Not only can I observe heaps of 304 responses for yarnds in my access log, but in Cache.FetchFeeds(…) we can actually see If-Modified-Since being deployed when the feed has been retrieved with a Last-Modified response header before: https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/cache.go#L1278

Turns out etags with If-None-Match are only supported when yarnd serves avatars (https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/handlers.go#L158) and media uploads (https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/media_handlers.go#L71). However, it ignores possible etags when fetching feeds.

I don’t understand how the discovery URLs should work to replace the User-Agent header in HTTP(S) requests. Do you mind to elaborate?

Different protocols are basically just a client thing.

I reckon it’s best to just avoid mixing several languages in one feed in the first place. Personally, I find it okay to occasionally write messages in other languages, but if that happens on a more regularly basis, I’d definitely create a different feed for other languages.

Isn’t the emoji thing “just” a client feature? So, feed do not even have to state any emojis. As a user I’d configure my client to use a certain symbol for feed ABC. Currently, I can do a similar thing in tt where I assign colors to feeds. On the other hand, what if a user wants to control what symbol should be displayed, similar to the feed’s nick? Hmm. But still, my terminal font doesn’t even render most of emojis. So, Unicode boxes everywhere. This makes me think it should actually be a only client feature.

ProcessOne: Thoughts on Improving Messaging Protocols — Part 2, Matrix

Image

In the first part of this blog post, I explained how the Matrix protocol works, contrasted its design philosophy with XMPP, and discussed why these differences lead to … ⌘ Read more

Ignite Realtime Blog: Openfire 4.9.1 release
The Ignite Realtime community is happy to be able to announce the immediate availability of version 4.9.1 of Openfire, its cross-platform real-time collaboration server based on the XMPP protocol!

4.9.1 is a bugfix and maintenance release. Among its most important fixes is one for a memory leak that affected all recent versions of Openfire (but was likely noticeable on … ⌘ Read more

(#lci25ga) @asquare Why “frightening”? And what does “protocol ossification” mean? Hmm 🧐
@asquare @asquare.srht.site Why “frightening”? And what does “protocol ossification” mean? Hmm 🧐 ⌘ Read more

(#pqhbula) @Codebuzz I really like this idea of just using the Feed’s # nick as a sort of “identifier”. This gets us out of this mess of when …
@Codebuzz @www.codebuzz.nl I really like this idea of just using the Feed’s # nick as a sort of “identifier”. This gets us out of this mess of when feeds move locations or authors decide to host on 3 or 4 different protocols 🤣 Downside? Something picks the same nick? ( _they’ll still hash differently, so th … ⌘ Read more

@movq@www.uninformativ.de How hard would it be to implement something like (#<2024-10-25T17:15:50Z https://www.uninformativ.de/twtxt.txt>)in jenny as a replacement for (#twthash) and have it not care about if is http(s) or a g-protocol?

Simplified twtxt - I want to suggest some dogmas or commandments for twtxt, from where we can work our way back to how to implement different feature like replies/treads:

1. It’s a text file, so you must be able to write it by hand (ie. no app logic) and read by eye. If you edit a post you change the content not the timestamp. Otherwise it will be considered a new post.

2. The order of lines in a twtxt.txt must not hold any significant. The file is a container and each line an atomic piece of information. You should be able to run sort on a twtxt.txt and it should still work.

3. Transport protocol should not matter, as long as the file served is the same. Http and https are preferred, so it is suggested that feed served via Gopher or Gemini also provide http(s).

4. Do we need more commandments?

ProcessOne: ProcessOne Unveils New Website
We’re excited to announce the relaunch of our website, designed to better showcase our expertise in large-scale messaging solutions, highlighting our full spectrum of supported protocols—from XMPP to MQTT and Matrix. This reflects our core strength: delivering reliable messaging at scale.

The last major redesign was back in October 2017, so this update was long overdue. As we say farewell to the old design, here’s a screenshot of the previous version to commemorate … ⌘ Read more

ESP32-C5-DevKitC-1 with 240MHz RISC-V Processor, Zigbee, and Thread Connectivity
The ESP32-C5-DevKitC-1 is another upcoming entry-level development board designed for IoT applications, featuring the ESP32-C5-WROOM-1 module. This board supports key wireless protocols, including Wi-Fi 6 (2.4 GHz and 5 GHz), Bluetooth LE 5, Zigbee, and Thread. The ESP32-C5-WROOM-1 module is equipped with a 32-bit RISC-V single-core processor running at 240 MHz along with 384 KB […] ⌘ Read more

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

Kewbit posts first progress report for ‘Haveno App’ CCS proposal
Kewbit1 has posted the first progress report2 for their CCS proposal to continue developing the Haveno App 3 (previously known as Haveno Plus):

Focusing specifically on the Protocol Interface milestone, I have implemented the full scope of gPRC interfacing in Dart and already hooked a considerable amount of it into the app itself, almost to the point of completion [..] Thank you for your … ⌘ Read more

Ignite Realtime Blog: XMPP: The Protocol for Open, Extensible Instant Messaging

XMPP, the Extensible Messaging and Presence Protocol, is an Instant Messaging (IM) standard of the Internet Engineering Task Force (IETF) - the same organization that standardized Email (POP/IMAP/SMTP) and the World Wide Web (HTTP) protocols. XMPP evolved out of the early XML streaming technology developed by the XMPP Open Source community and is now the leading pro … ⌘ Read more

ProcessOne: Matrix and XMPP: Thoughts on Improving Messaging Protocols – Part 1
For over two decades, ProcessOne has been developing large-scale messaging platforms, powering some of the largest services in the world. Our mission is to build the best messaging back-ends imaginable–an exciting yet complex challenge.

We began with XMPP (eXtensible Messaging and Presence Protocol), but the need for interoperability and support for a variety of use cases led us to implemen … ⌘ Read more

JMP: CertWatch
As you may have already seen, on October 21st, it was reported that a long-running, successful MITM (Machine-In-The-Middle) attack against jabber.ru had been detected. The nature of this attack was not specific to the XMPP protocol in any way, but it was of special interest to us as members of the XMPP community. This kind of attack relies on being able to present a TLS certificate which anyone trying to connect will accept as valid. In this case, it was done b … ⌘ Read more

@bender@twtxt.net I believe it is Unix-Unix Copy Protocol. Not Unix Copy-Copy Protocol.

@bender@twtxt.net I believe it is Unix-Unix Copy Protocol. Not Unix Copy-Copy Protocol.

@anth@a.9srv.net you wrote:

“Edits and Deletions should go; see also Section 6. This is probably the worst example of this document pushing a text document to do more protocol-like things.”

Edit and deletions are precisely what brought us here. Currently, if one replies to a twtxt, and the original gets later edited, it breaks replies, and potentially drastically changes context.

@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’m still more in favor of (replyto:…). It’s easier to implement and the whole edits-breaking-threads thing resolves itself in a “natural” way without the need to add stuff to the protocol.

I’d love to try this out in practice to see how well it performs. 🤔 It’s all very theoretical at the moment.

Ignite Realtime Blog: Openfire 4.9.0 release!
The Ignite Realtime community is happy to be able to announce the immediate availability of version 4.9.0 of Openfire, its cross-platform real-time collaboration server based on the XMPP protocol!

As compared to the previous non-patch release, this one is a bit smaller. This mostly is a maintenance release, and includes some preparations (deprecations, mainly) for a f … ⌘ Read more

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.

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?

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

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 ?

@xuu@txt.sour.is Thanks for the link. I found a pdf on one of the authors’ home pages: https://ahmadhassandebugs.github.io/assets/pdf/quic_www24.pdf . I wonder how the protocol was evaluated closer to the time it became a standard, and whether anything has changed. I wonder if network speeds have grown faster than CPU speeds since then. The paper says the performance is around the same below around 600 Mbps.

To be fair, I don’t think QUIC was ever expected to be faster for transferring a single stream of data. I think QUIC is supposed to reduce the impact of a dropped packet by making sure it only affects the stream it’s part of. I imagine QUIC still has that advantage, and this paper is showing the other side of a tradeoff.

So this is a great thread. I have been thinking about this too.. and what if we are coming at it from the wrong direction? Identity being tied to a given URL has always been a pain point. If i get a new URL its almost as if i have a new identity because not only am I serving at a new location but all my previous communications are broken because the hashes are all wrong.

What if instead we used this idea of signatures to thread the URLs together into one identity? We keep the URL to Hash in place. Changing that now is basically a no go. But we can create a signature chain that can link identities together. So if i move to a new URL i update the chain hosted by my primary identity to include the new URL. If i have an archived feed that the old URL is now dead, we can point to where it is now hosted and use the current convention of hashing based on the first url:

The signature chain can also be used to rotate to new keys over time. Just sign in a new key or revoke an old one. The prior signatures remain valid within the scope of time the signatures were made and the keys were active.

The signature file can be hosted anywhere as long as it can be fetched by a reasonable protocol. So say we could use a webfinger that directs to the signature file? you have an identity like frank@beans.co that will discover a feed at some URL and a signature chain at another URL. Maybe even include the most recent signing key?

From there the client can auto discover old feeds to link them together into one complete timeline. And the signatures can validate that its all correct.

I like the idea of maybe putting the chain in the feed preamble and keeping the single self contained file.. but wonder if that would cause lots of clutter? The signature chain would be something like a log with what is changing (new key, revoke, add url) and a signature of the change + the previous signature.

# chain: ADDKEY kex14zwrx68cfkg28kjdstvcw4pslazwtgyeueqlg6z7y3f85h29crjsgfmu0w 
# sig: BEGIN SALTPACK SIGNED MESSAGE. ... 
# chain: ADDURL https://txt.sour.is/user/xuu
# sig: BEGIN SALTPACK SIGNED MESSAGE. ...
# chain: REVKEY kex14zwrx68cfkg28kjdstvcw4pslazwtgyeueqlg6z7y3f85h29crjsgfmu0w
# sig: ...

So this is a great thread. I have been thinking about this too.. and what if we are coming at it from the wrong direction? Identity being tied to a given URL has always been a pain point. If i get a new URL its almost as if i have a new identity because not only am I serving at a new location but all my previous communications are broken because the hashes are all wrong.

What if instead we used this idea of signatures to thread the URLs together into one identity? We keep the URL to Hash in place. Changing that now is basically a no go. But we can create a signature chain that can link identities together. So if i move to a new URL i update the chain hosted by my primary identity to include the new URL. If i have an archived feed that the old URL is now dead, we can point to where it is now hosted and use the current convention of hashing based on the first url:

The signature chain can also be used to rotate to new keys over time. Just sign in a new key or revoke an old one. The prior signatures remain valid within the scope of time the signatures were made and the keys were active.

The signature file can be hosted anywhere as long as it can be fetched by a reasonable protocol. So say we could use a webfinger that directs to the signature file? you have an identity like frank@beans.co that will discover a feed at some URL and a signature chain at another URL. Maybe even include the most recent signing key?

From there the client can auto discover old feeds to link them together into one complete timeline. And the signatures can validate that its all correct.

I like the idea of maybe putting the chain in the feed preamble and keeping the single self contained file.. but wonder if that would cause lots of clutter? The signature chain would be something like a log with what is changing (new key, revoke, add url) and a signature of the change + the previous signature.

# chain: ADDKEY kex14zwrx68cfkg28kjdstvcw4pslazwtgyeueqlg6z7y3f85h29crjsgfmu0w 
# sig: BEGIN SALTPACK SIGNED MESSAGE. ... 
# chain: ADDURL https://txt.sour.is/user/xuu
# sig: BEGIN SALTPACK SIGNED MESSAGE. ...
# chain: REVKEY kex14zwrx68cfkg28kjdstvcw4pslazwtgyeueqlg6z7y3f85h29crjsgfmu0w
# sig: ...

HTTP/2 differs from 1.x by becoming a binary protocol, it also multiplexes multiple channels over the same connection and has the ability to prefetch related content to the browser to lower the perceived latency.

HTTP/3 moves the binary protocol from HTTP/2 over to QUIC which is based on UDP instead of TCP. This makes it better suited to mobile or unstable networks where handling of transmission errors can be handled at a higher level.

HTTP/2 differs from 1.x by becoming a binary protocol, it also multiplexes multiple channels over the same connection and has the ability to prefetch related content to the browser to lower the perceived latency.

HTTP/3 moves the binary protocol from HTTP/2 over to QUIC which is based on UDP instead of TCP. This makes it better suited to mobile or unstable networks where handling of transmission errors can be handled at a higher level.

ESP32-S3-Based WiCAN Pro: An OBD Scanner for Vehicle Diagnostics and Home Assistant Integration
Crowd Supply recently featured the WiCAN Pro, a diagnostic OBD scanner designed to support advanced automotive diagnostics. Built on the ESP32-S3 platform, it offers compatibility with all legislated OBD-II protocols, allowing it to interface with multiple CAN BUS protocols, including three standard CAN protocols and one Single Wire CAN. WiCAN Pro operate … ⌘ Read more

Affordable RISC-V Development Board Built Around 32-bit QingKe CH32V003 Processor
Tindie recently featured a development kit designed to evaluate and leverage the capabilities of the low-cost CH32V003 microcontroller. Key features include multiple GPIOs, support for various communication protocols, a small OLED interactive display, and tutorials to help users learn to interface with the product. The CH32V003 is a 32-bit MCU based on the RISC-V 2A […] ⌘ Read more

These things are befitting to younger protocols unsure of themselves.

And having meta discussions about the protocol itself all day.

ProcessOne: Understanding messaging protocols: XMPP and Matrix
In the world of real-time communication, two prominent protocols often come into discussion: XMPP and Matrix. Both protocols aim to provide robust and secure messaging solutions, but they differ in architecture, features, and community adoption. This article delves into the key differences and similarities between XMPP and Matrix to help you understand which might be better suited for your needs.

XMPP (Extensible Messaging and … ⌘ Read more

ProcessOne: Understanding messaging protocols: XMPP and Matrix
In the world of real-time communication, two prominent protocols often come into discussion: XMPP and Matrix. Both protocols aim to provide robust and secure messaging solutions, but they differ in architecture, features, and community adoption. This article delves into the key differences and similarities between XMPP and Matrix to help you understand which might be better suited for your needs.

XMPP (Extensible Messaging and … ⌘ Read more

ProcessOne: Understanding messaging protocols: XMPP and Matrix
In the world of real-time communication, two prominent protocols often come into discussion: XMPP and Matrix. Both protocols aim to provide robust and secure messaging solutions, but they differ in architecture, features, and community adoption. This article delves into the key differences and similarities between XMPP and Matrix to help you understand which might be better suited for your needs.

XMPP (Extensible Messaging and … ⌘ Read more

ProcessOne: Understanding messaging protocols: XMPP and Matrix
In the world of real-time communication, two prominent protocols often come into discussion: XMPP and Matrix. Both protocols aim to provide robust and secure messaging solutions, but they differ in architecture, features, and community adoption. This article delves into the key differences and similarities between XMPP and Matrix to help you understand which might be better suited for your needs.

XMPP (Extensible Messaging and … ⌘ Read more

Matter 1.3 Specification Adds Energy Reporting, Electric Vehicle Charging, Water Management Support and More
The Connectivity Standards Alliance (CSA) today announced the debut of a new Matter 1.3 specification that’s available for device makers and platforms. Matter is a smart home protocol that allows smart devices to work across multiple platforms, including HomeKit.

Image

Matt … ⌘ Read more

Go 通過 grpc-protobuf 實現高性能用戶服務實戰，從 0 到 1 超級詳細流程！！
基礎知識準備在在代碼實戰 gRPC 之前，我們需要了解一些基礎知識：RPC（Remote Procedure Call）：遠程過程調用，是一種通信協議，允許應用程序在不同的計算機上請求服務而不需要了解底層網絡細節。 gRPC：gRPC 是一種高性能、開源的遠程過程調用（RPC）框架，由 Google 開發，並基於 HTTP/2、Protocol Buffers 等技術實現。 Proto ⌘ Read more

(Updated) Open source ESP32 module supports 5G and GPS connectivity
CrowdSupply recently featured, the Walter embedded device equipped with the ESP32-S3 microcontroller along with a GM02SP module for NB-IoT, LTE-M and GPS protocols. The board is CE and FCC certified to accelerate customers’ product development. Built around the ESP32-S3-WROOM-1-N16R2 microcontroller, Walter boasts an advanced core architecture and connectivity options. It features a Xtensa dual-core 32-bit LX7 … ⌘ Read more

Erlang Solutions: gen_statem Unveiled

This blog post is a deep dive into some of the concepts discussed in my recent conference talk at FOSDEM. The presentation explored some basic theoretical concepts of Finite State Machines, and some special powers of Erlang’s gen_statem in the context of protocols and event-driven development, and building upon this insi … ⌘ Read more

Erlang Solutions: gen_statem Unveiled

This blog post is a deep dive into some of the concepts discussed in my recent conference talk at FOSDEM. The presentation explored some basic theoretical concepts of Finite State Machines, and some special powers of Erlang’s gen_statem in the context of protocols and event-driven development, and building upon this insi … ⌘ Read more

hewwo :3 I love gemini protocol. gemini://gemlog.blue/users/546pvp/1709922234.gmi

So where do we start wring down the specs/protocol for twtxt2/yarn?

ePulse Feather C6: A RISC-V Powered Board with Advanced Zigbee, Thread, and BLE Connectivity
The ePulse Feather C6 by ThingPulse distinguishes itself in the ESP32-C6 development board category, supporting an array of communication protocols including Wi-Fi, BLE, Zigbee, Thread, and Matter. Its low power consumption and flexible power input make it suitable for a wide range of IoT applications. At its core, the ePulse Feather C6 features the ESP32-C6-MI … ⌘ Read more

@shreyan@twtxt.net What do you mean when you say federation protocol?

• Either use webfinger for identity like mastodon etc. or use ATproto from Bluesky (or both?)

• We can use webmentions or create our own twt-mentions for notifying someones feed (WIP code at: https://github.com/sorenpeter/timeline/tree/webmention/views)

I’m not sure we need much else. I would not even bother with encryption since other platforms does that better, and for me twtxt/yarn/timeline is for making things public

yarn should define its own federation protocol that extends the basic twtxt in ways that twtxt doesn’t allow. it’s time. and i’ve got ideas!

Olivier’s 13 punches to Rempe’s six resulted in Rempe being sent for concussion protocols
Olivier landed 13 punches to Rempe’s six, and Rempe was sent to the locker room for concussion protocols before returning later in the first period. ⌘ Read more

Hungary’s parliament has ratified Sweden’s bid to join NATO
The vote, which passed with 188 votes for and six against, came as a culmination of months of wrangling by Hungary’s allies to convince its nationalist government to lift its block on Sweden’s membership. The government of Prime Minister Viktor Orbán submitted the protocols for approving Sweden’s entry into NATO in July 2022, but the matter had stalled in parliament over opposition b … ⌘ Read more

I would love to see a world where ones twtxt feed is defined by webfinger. So @xuu@txt.sour.is => https://text.sour.is/user/xuu/twtxt.txt

Then my identity can exist independent of the feed location. And I can host multiple protocol types for my feed. Ie. http/gopher/Gemini/irc DCC/etc

I would love to see a world where ones twtxt feed is defined by webfinger. So @xuu@txt.sour.is => https://text.sour.is/user/xuu/twtxt.txt

Then my identity can exist independent of the feed location. And I can host multiple protocol types for my feed. Ie. http/gopher/Gemini/irc DCC/etc

I’m also more in favor of #reposts being human readable and writable. A client might implement a bottom that posts something simple like: #repost Look at this cool stuff, because bla bla [alt](url)

This will then make it possible to also “repost” stuff from other platforms/protocols.

The reader part of a client, can then render a preview of the link, which we talked about would be a nice (optional) feature to have in yarnd.

DFRobot Coin-Sized ESP32-C6 Board with RISC-V Core, Priced at $4.90
The Beetle ESP32-C6 is a compact and versatile IoT development board by DFRobot, designed for Arduino enthusiasts and developers looking to explore low-power IoT solutions. This tiny gizmo offers up to 16x I/Os and an array of communication protocols including Wi-Fi 6, Bluetooth 5, Zigbee 3.0, and Thread 1.3. This device utilizes the same Espressif […] ⌘ Read more

Go 一文帶你喫透 HTTP 客戶端！
*1. HTTP 請求簡介HTTP(Hypertext Transfer Protocol) 是構建 web 應用通信的基石。HTTP 工作於客戶端 - 服務端架構上。HTTP 客戶端發起請求, 服務器接收請求並返回響應。HTTP 請求主要由請求行、請求頭、請求體組成請求行 GET /search?name=Golang HTTP/1.1請求頭部 Host: www.baidu ⌘ Read more

Ignite Realtime Blog: Creating the XMPP Network Graph
At the risk of sounding like an unhinged fanboy: XMPP is pretty awesome!

I’ve been involved in one way or another with XMPP, the network protocol that is an open standard for messaging and presence, for the last two decades. Much of that revolves around development of Openfire, our XMPP-based real-time communications server.

TL;DR:

• I built a thing:[https://xmppnetwork.goodbytes.i … ⌘ Read more

Go 語言與 gRPC 的完美結合
*一、gRPC 簡介gRPC(Remote Procedure Call) 是一種遠程過程調用技術, 通過壓縮和序列化數據來優化網絡通信, 可以顯著提高服務調用的性能和效率。gRPC 的概念gRPC 是一個高性能、通用的開源 RPC 框架, 是一個由 Google 主導開發的 RPC 框架。其以 HTTP/2 爲基礎通信協議, 支持多種語言, 通過 protocol buffers 數據格式來實現 ⌘ Read more

Ignite Realtime Blog: Openfire 4.8.0 Released!
The Ignite Realtime community is happy to be able to announce the immediate availability of version 4.8.0 of Openfire, its cross-platform real-time collaboration server based on the XMPP protocol!

This is the first major release of Openfire in about two years, and that shows: 199 tickets have been closed against this release! As a fun fact: the oldest of these issues was raised in 2015, the youngest: three days ago. Some of the highlights in this relea … ⌘ Read more

Quectel and Morse Micro Launch First Wi-Fi HaLow Module with CE and FCC Certifications
Quectel and Morse Micro have launched the first Wi-Fi HaLow module, the Quectel FGH100M, achieving both CE and FCC certifications. These certifications, backed by Morse Micro’s MM6108 SoC, confirm the module’s strict adherence to top safety and environmental standards in both regions. This certification allows the Wi-Fi HaLow protocol to expand its global presence across … ⌘ Read more

The XMPP Standards Foundation: XMPP Summit 26
The XMPP Standards Foundation (XSF) will hold its 26th XMPP Summit in Brussels, Belgium this year again!
These are the two days preceding FOSDEM 2024.
The XSF invites everyone interested in development of the XMPP protocol to attend, and discuss all things XMPP in person and remote!

The venue will take place at the Thon Hotel EU including coffee break (from 08:30 o’clock) and lunch (12:00 to 14:00 o’clock) paid b … ⌘ Read more

Ignite Realtime Blog: Happy Birthday, Jabber!
Today marks the 25th birthday of Jeremie Miller’s announcement of “a new project to create a complete open-source platform for Instant Messaging” on Slashdot.

How have things progressed since then!

By far most of the projects that we maintain here in the IgniteRealtime.org community make direct use of the XMPP protocol, which is the name used for t … ⌘ Read more

ProcessOne: Matrix protocol added to ejabberd
ejabberd is already the most versatile and scalable messaging server. In this post, we are giving a sneak peak at what is coming next.

ejabberd just get new ace in it sleeve – you can now use ejabberd to talk with other Matrix servers, a protocol sometimes used for small corporate server messaging.

Of course, you all know ejabberd supports the XMPP instant messaging protocol with hundreds of XMPP extensions, this is what it is famous for.

The second ma … ⌘ Read more

Ignite Realtime Blog: Dan is voted in the XSF’s Council!
Our very own @danc was voted into the XMPP Standards Foundation Council not to long ago!

The XMPP Standards Foundation is an independent, nonprofit standards development organisation whose primary mission is to define open protocols for presence, instant messaging, and real-time communication and collaboration on top of the IETF’s Extensible Messagin … ⌘ Read more

ProcessOne: Instant Messaging: Protocols are “Commons”, Let’s Take Them Seriously
TLDR;

**Thirty years after the advent of the first instant messaging services, we still haven’t reached the stage where instant messaging platforms can freely communicate with each other, as is the case with email. In 1999, the Jabber/XMPP protocol was created and standardized for this purpose by the Internet Engineering Task Force (IETF). Since then, proprietary messaging services ha … ⌘ Read more

ProcessOne: Instant Messaging: Protocols are “Commons”, Let’s Take Them Seriously
TLDR;

**Thirty years after the advent of the first instant messaging services, we still haven’t reached the stage where instant messaging platforms can freely communicate with each other, as is the case with email. In 1999, the Jabber/XMPP protocol was created and standardized for this purpose by the Internet Engineering Task Force (IETF). Since then, proprietary messaging services ha … ⌘ Read more

ProcessOne: Instant Messaging: Protocols are “Commons”, Let’s Take Them Seriously
TLDR;

**Thirty years after the advent of the first instant messaging services, we still haven’t reached the stage where instant messaging platforms can freely communicate with each other, as is the case with email. In 1999, the Jabber/XMPP protocol was created and standardized for this purpose by the Internet Engineering Task Force (IETF). Since then, proprietary messaging services ha … ⌘ Read more

ProcessOne: Instant Messaging: Protocols are “Commons”, Let’s Take Them Seriously
TLDR;

**Thirty years after the advent of the first instant messaging services, we still haven’t reached the stage where instant messaging platforms can freely communicate with each other, as is the case with email. In 1999, the Jabber/XMPP protocol was created and standardized for this purpose by the Internet Engineering Task Force (IETF). Since then, proprietary messaging services ha … ⌘ Read more

Erlang Solutions: MongooseIM 6.2: Easy to set up, use and manage
MongooseIM, which is our scalable, flexible and cost-efficient instant messaging server, is now easier to use than ever before. The latest release 6.2 introduces a completely new CETS in-memory storage backend, letting you easily deploy it with modern cloud infrastructure solutions such as Kubernetes. The XMPP extensions are also updated, which means that we support new features of the XMPP protocol.

The new version of MongooseIM is very easy to tr … ⌘ Read more

Вышла бесплатная русская озвучка The Callisto Protocol от Mechanics VoiceOver
Желающие уже могут её скачать.

Image

Sam Whited: Software is Political

I recently attended the inaugural Free and Open Source Software Yearly ( FOSSY)
conference where I gave a talk in the XMPP track.
Though my talk was just a brief technical overview of the XMPP protocol, I also
gave some quick ending remarks about why I think it’s the correct choice to use
as a universal standardized chat protocol.
The closing remarks were written … ⌘ Read more

JMP: CertWatch
As you may have already seen, on October 21st, it was reported that a long-running, successful MITM (Machine-In-The-Middle) attack against jabber.ru had been detected. The nature of this attack was not specific to the XMPP protocol in any way, but it was of special interest to us as members of the XMPP community. This kind of attack relies on being able to present a TLS certificate which anyone trying to connect will accept as valid. In this case, it was done b … ⌘ Read more

Check out the Nex Protocol. It’s designed to be even simpler than Gemini and Gopher. What do you think? Could be great to host a twtxt feed on.

Can’t wait until this site joins the trend and becomes “y.com” - the everything protocol.

Erlang Solutions: Unleashing the Power of SNMP: Exposing Your Embedded Elixir/Erlang (Nerves, GRiSP) Apps to the World
Did you know that Erlang/OTP ships with built-in SNMP  (Simple Network Management Protocol) support? Using SNMP is a great way to integrate your Elixir or Erlang application into an industrial environment. This will be of particular interest for those working with embedded … ⌘ Read more

Long live gopher! We need to develop more gopher pages like this ones, this protocol is amazing

The Apple IIgs gets a new Gopher client. Seriously.
A computer discontinued 30 years ago & a TCP protocol left for dead. Awesome. ⌘ Read more

ProcessOne: ejabberd 22.10
This ejabberd 22.10 release includes six months of work, over 140 commits, including relevant improvements in MIX, MUC, SQL, and installers, and bug fixes as usual.

Image

This version brings support for latest MIX protocol version, and significantly improves detection and recovery of SQL connection issues.

There are no breaking changes in SQL schem … ⌘ Read more

💡 Quick ‘n Dirty prototype Yarn.social protocol/spec:

If we were to decide to write a new spec/protocol, what would it look like?

Here’s my rough draft (back of paper napkin idea):

• Feeds are JSON file(s) fetchable by standard HTTP clients over TLS
  
• WebFinger is used at the root of a user’s domain (or multi-user) lookup. e.g: prologic@mills.io -> https://yarn.mills.io/~prologic.json
  
• Feeds contain similar metadata that we’re familiar with: Nick, Avatar, Description, etc
  
• Feed items are signed with a ED25519 private key. That is all “posts” are cryptographically signed.
  
• Feed items continue to use content-addressing, but use the full Blake2b Base64 encoded hash.
  
• Edited feed items produce an “Edited” item so that clients can easily follow Edits.
  
• Deleted feed items produced a “Deleted” item so that clients can easily delete cached items.
  

#Yarn.social #Protocol #Ideas

I played around with parsers. This time I experimented with parser combinators for twt message text tokenization. Basically, extract mentions, subjects, URLs, media and regular text. It’s kinda nice, although my solution is not completely elegant, I have to say. Especially my communication protocol between different steps for intermediate results is really ugly. Not sure about performance, I reckon a hand-written state machine parser would be quite a bit faster. I need to write a second parser and then benchmark them.

lexer.go and newparser.go resemble the parser combinators: https://git.isobeef.org/lyse/tt2/-/commit/4d481acad0213771fe5804917576388f51c340c0 It’s far from finished yet.

The first attempt in parser.go doesn’t work as my backtracking is not accounted for, I noticed only later, that I have to do that. With twt message texts there is no real error in parsing. Just regular text as a “fallback”. So it works a bit differently than parsing a real language. No error reporting required, except maybe for debugging. My goal was to port my Python code as closely as possible. But then the runes in the string gave me a bit of a headache, so I thought I just build myself a nice reader abstraction. When I noticed the missing backtracking, I then decided to give parser combinators a try instead of improving on my look ahead reader. It only later occurred to me, that I could have just used a rune slice instead of a string. With that, porting the Python code should have been straightforward.

Yeah, all this doesn’t probably make sense, unless you look at the code. And even then, you have to learn the ropes a bit. Sorry for the noise. :-)

Ignite Realtime Blog: Release v1.1.0 of the MUC Real-Time Block List plugin for Openfire
We are happy to announce the immediate availability of a new version of the MUC Real-Time Block List plugin for Openfire, our cross-platform real-time collaboration server based on the XMPP protocol! This plugin can help you moderate your chat rooms, especially when your service is part of a larger network of federate … ⌘ Read more

OAuth Support in Bluesky and AT Protocol
Bluesky, a new social media platform and AT Protocol, is unsurprisingly running up against the same challenges and limitations that Flickr, Twitter and many other social media platforms faced in the 2000s: passwords! ⌘ Read more

Ignite Realtime Blog: New: Openfire MUC Real-Time Block List plugin!
A new plugin has been made available for Openfire, our cross-platform real-time collaboration server based on the XMPP protocol. We have named this new plugin the MUC Real-Time Block List plugin.

This plugin can help you moderate your chat rooms, especially when your service is part of a larger network of federated XMPP domains. From experience, the XMPP community has learned that bad actors tend to spam a wid … ⌘ Read more

Dino: Dino 0.4 Release
Dino is a secure and open-source messaging application.
It uses the XMPP (Jabber) protocol for decentralized communication.
We aim to provide an intuitive and enjoyable user interface.

The 0.4 release adds support for message reactions and replies. We also switched from GTK3 to GTK4 and make use of libadwaita now.

Image

Reactions give you a quick and light-weight way to respond to a message with an emoji.
They … ⌘ Read more

Paul Schaub: Use Any SOP Binary With SOP-Java and External-SOP
The Stateless OpenPGP Protocol specification describes a shared, standardized command line interface for OpenPGP applications. There is a bunch of such binaries available already, among them PGPainless’ pgpainless-cli, Sequoia-PGP’s sqop, as well as ProtonMails [gosop](https://github.com/ProtonMa … ⌘ Read more

@prologic@twtxt.net On the one hand, twtxt has become more popular thanks to Yarn.social. On the other hand, subject and hashtag extensions took away the simplicity of the protocol. For example, it is impossible to understand which conversation (#base32hash) a tweet refers to or to reply to a tweet without going to a yarn.social pod. Compare with re: in this tweet which can be written without using any client at all

I’ve been exploring the Fediverse, ActivityPub protocol, Mastodon, etc.

JMP: Writing a Chat Client from Scratch
There are a lot of things that go into building a chat system, such as client, server, and protocol.  Even for only making a client there are lots of areas of focus, such as user experience, features, and performance.  To keep this post a manageable size, we will just be building a client and will use an existing server and protocol (accessing Jabber network services using the XMPP protocol).  We’ll make a practical GUI so we can test things, but not spend too much time on p … ⌘ Read more

Prosodical Thoughts: Bringing FASTer authentication to Prosody and XMPP
As our work continues on modernizing XMPP authentication,
we have some more new milestones to share with you. Until now our work has
mostly been focused on internal Prosody improvements, such as the new roles\
and permissions framework. Now we are starting to extend our
work to the actual client-to-server protocol in XMPP.

Prosody and [Snikket](https://snik … ⌘ Read more

Oh wow! 😳 Looks like Mastodon are planning to add support for Twtxt in Add support for Twtxt protocol 😅

The AT Protocol ?~L~X https://notiz.blog/b/6AM

ProcessOne: Matrix protocol added to ejabberd
ejabberd is already the most versatile and scalable messaging server. In this post, we are giving a sneak peak at what is coming next.

ejabberd just get new ace in it sleeve – you can now use ejabberd to talk with other Matrix servers, a protocol sometimes used for small corporate server messaging.

Of course, you all know ejabberd supports the XMPP instant messaging protocol with hundreds of XMPP extensions, this is what it is famous for.

The second ma … ⌘ Read more

Network Time Protocol (NTP) - Computerphile ⌘ Read more

ProcessOne: ejabberd 22.10
This ejabberd 22.10 release includes six months of work, over 140 commits, including relevant improvements in MIX, MUC, SQL, and installers, and bug fixes as usual.

Image

This version brings support for latest MIX protocol version, and significantly improves detection and recovery of SQL connection issues.

There are no breaking changes in SQL schem … ⌘ Read more