💬 Matrix and XMPP: Thoughts on Improving Messaging Protocols – Part 1

「 If the Matrix network were to scale massively, with many nodes and conversations, it would encounter the same growth challenges as blockchain protocols. Each node must store a copy of the conversation, and the amount of replication depends on the number of conversations and nodes globally. As these numbers grow, so does the replication factor 」

https://www.process-one.net/blog/matrix-and-xmpp-thoughts-on-improving-messaging-protocols-part-1/

#matrix #xmpp #distsys

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.

ProcessOne
Categorizing How Distributed Databases Utilize Consensus Algorithms

Distributed databases generally fall into two camps when it comes to architectures for maintaining high availability (HA) [1]. Both architectures are used by many successful production systems, but…

Medium
A three way light switch is one in which the wiring of a switch you didn't even know existed can render your own switch unusable.
#DistSys #HomeImprovement
Predicting the Future of Distributed Systems.
[Object storage and new programming models 🤔]
https://blog.colinbreck.com/predicting-the-future-of-distributed-systems/
#DistSys
Predicting the Future of Distributed Systems

There are significant changes happening in distributed systems.

Colin Breck
Are you interested in and posting on topics like: #Messaging, #MQTT, #IoT, #OpenSource, #DistSys, #Erlang, OSS business models or anything related?
Let us know by Like of Repost... We want to follow you! :) 

Just discovered Radicle (https://radicle.xyz/), which is a peer-to-peer git forge. It has its own custom gossip protocol to propagate repo changes through the different instances.

Even if i LOVE gossip protocols, I'm still a little bit confused about all of these "distributed" forges, mainly because git is already distributed by default (https://git-scm.com/about/distributed).

Radicle authors are answering this question in their FAQ (https://radicle.xyz/faq):

```
While Git is designed in some way for peer-to-peer interactions, there is no deployment of it that works that way. All deployments use the client-server model because Git lacks functionality to be deployed as-is in a peer-to-peer network.

For one, it has no way of verifying that the repository you downloaded after a git clone is the one you asked for, which means you need to clone from a trusted source (ie. a known server). This isn’t compatible with peer-to-peer in any useful way.

Radicle solves this by assigning stable identities to repositories that can be verified locally, allowing repositories to be served by untrusted parties.
```

I'm still not convinced though, I think it's adding lots of complexity to an already complex system.

#git #distsys

Radicle: the sovereign forge

Sovereign code infrastructure.

Just came across Epoxy, a protocol that aims to allow transactions between different datastores. I haven't read the paper yet (but I will), as these are some serious allegations :D

https://petereliaskraft.net/blog/epoxy

#distsys

Transactions Across Data Stores

Using Promise Theory to solve the distributed consensus problem

Whenever we try to fix something in one corner of IT, we seem to yank another corner out of place and create new problems–trading one conundrum for another. Microservices are a perfect example of…

Medium
A quick post about Lamport clocks, and a tla+ specification to solve the mutual exclusion problem based on the algorithm described by Lamport in his paper Time, Clocks, and the Ordering of Events in a Distributed System.
https://blog.fponzi.me/2024-02-02-lamport-clocks.html
#distsys
Lamport clocks

Last weekend I wanted to get some inspiration to write some TLA+ spec and I got my hands back on the paper Time, Clocks, and the Ordering of Events...