Partisan is a scalable and flexible, TCP-based membership system and distribution layer for the BEAM. It bypasses the use of Distributed Erlang for manual connection management via TCP, and has several pluggable backends for different deployment scenarios.

Partisan is a runtime system that enables greater scalability and reduced latency for distributed actor applications.

• Partisan improves scalability by allowing the application developer to specialize the overlay network to the application’s communication patterns.
• Partisan achieves lower latency by leveraging several predominately automatic optimizations that result in the efficient scheduling of messages.
• Bring Your Own Overlay - Partisan exposes an API for users to implement their own overlays; application developers must simply implement the membership_strategy interface for handling messages. Partisan automatically uses this membership strategy for processing incoming and outgoing messages to the system – the application developer only needs to handle internal state transitions and supplying the system with an updated list of members. Partisan automatically sets up required connections, serializes and deserializes messages, performs failure detection, and message forwarding. This makes it possible to implement protocols with very little code; our implementation of the full-mesh membership protocol is 152 LOC.
• Partisan is the first distributed actor system to expose this level of control to the application developer, improving the performance of existing actor application and enabling new types of actor applications.

OpenWISP is a modular network management system built on top of OpenWRT (but designed to allow supporting multiple embedded operating systems) that allows managing and automating several aspects of IT network deployment, monitoring and management:

• registration/provisioning of new nodes
• creation of VPN tunnels
• possibility of defining configuration templates and configuration variables to make the maintenance of configurations easier and faster
• possibility of configuring mesh networks as well as wireless access points using WPA2, WPA3, 802.1x (WPA enterprise) , WPS, WEP, multiple SSIDs, etc.
• possibility of deploying any network configuration supported by OpenWRT
• monitoring, collection of metrics, active checks, threshold definition and alerts
• RADIUS (eg: for wifi access / hotspot systems or ISPs)
• responsive captive page with features like user registration, SMS verification, social login
• firmware upgrades
• web and email notifications for important events happening in the network
• network topology visualization for mesh networks and VPN networks

The preceding list is not an exhaustive list but more like an overview of what OpenWISP can do.

Fabio is an HTTP and TCP reverse proxy that configures itself with data from Consul.

Traditional load balancers and reverse proxies need to be configured with a config file. The configuration contains the hostnames and paths the proxy is forwarding to upstream services. This process can be automated with tools like consul-template that generate config files and trigger a reload.

Fabio works differently since it updates its routing table directly from the data stored in Consul as soon as there is a change and without restart or reloading.

When you register a service in Consul all you need to add is a tag that announces the paths the upstream service accepts, e.g. urlprefix-/user or urlprefix-/order and fabio will do the rest.

Amid all the conversation about Signal, and the debate over decentralization, one thing has often not been raised: all of these things require an Internet connection.

“Of course,” you might say. “Internet is everywhere these days.” Well, not so much, and it turns out there are some very good reasons that people might want messengers that work offline. Here are some examples:

• Internet-using messengers leak certain metadata (eg, that a person is using it, or perhaps a sophisticated adversary could use timing analysis to determine that two people are talking using it)
• Cell signal outages due to natural disaster, large influx of people (protests, unusual sporting events, festivals, etc), or other factors
• Locations where cell signals are not available (rural areas, camping locations, wilderness areas, etc.)
• Devices that don’t have cell data capability (many tablets, phones that have had service expire, etc.)