Ahem… I cannot be skeptical about activism more, but I don’t see any correlation about activism and fair play whatsoever. There is a huge room for playing fair and be a complete passivist (should I have used the word “idle” here?) in regard to any crowd actions. I mean, just eschew anything where your vote does not matter and put all the spared effort to something what really needs your skills and power.
mudasobwa
Creator of Cure
AstonJ
This just hit DT and looks interesting (not had a chance to look at it any detail yet)…
An open-source communications hardware & software initiative empowering the public to connect across the world by bouncing signals off the Moon—and more!
A New Frontier for Ham Radio
Bouncing signals off the Moon—known as Earth-Moon-Earth (EME) communication—has long been the ultimate challenge for radio amateurs. It required large antennas, expensive equipment, and accurate manual pointing and tracking. We try to bring this down to Earth, providing all the tools needed to experience the thrill of space communication, with an open source software-defined phased array.
Open-Source Hardware
Expected to ship: March 2026.
Our first kit is a low-cost digital phased array, with high transmit power and excellent receive sensitivity. It supports flexible transmission modes across any 40 MHz bandwidth in the C-band (4.9–6 GHz).
Array Development Kit
With a scalable architecture, you can pick an array size and grow later.
Quad: A Software-Defined Radio Tile
13 cm
Price: $49 - 99 (TBD)
Overview
This 4-antenna SDR tile designed for arraying. Drop-in compatible with Raspberry Pi pipelines (GNU Radio, Python/C++, SoapySDR) .
Useful as a standalone SDR or as a building block for larger phased arrays.Key features
- Frequency: 4.9–6.0 GHz (C-band), full duplex
- Per-antenna bandwidth: 40 MHz; 8+8-bit I/Q
- Tx power: 1 W per antenna • Rx NF: ~1.2 dB
- Polarization: RHCP (Tx), LHCP (Rx)
- MEMS TCXO • Jitter ~1.4 ps
- FPGA: Lattice ECP5 • Latency < 1 ms
- Power: 12 V DC (≈25 W peak)
Standalone applications
- General-purpose 4×4 MIMO Software-defined Radio
- Fox-hunting, direction of arrival (DOA), RF exploration
- Open Wi-Fi router, Open 4G/5G base station
- Drone HD links, robotics communications
2
vlmoon99
Anyone who is interested in smart contract development — I can build tools for creating smart contracts on the NEAR blockchain.
If this is something you’re interested in, please participate in the thread/poll.
NEAR Protocol Documentation | NEAR Documentation
And if you have any questions, I’ll be happy to answer them!
1
GrammAcc
This is an interesting discussion with a lot of sidebars, but thinking about the original question of the topic, I’ve always wanted REST to actually work.
REST is a beautiful idea. It takes advantage of how the web was actually designed as a “web of documents” and turns it into something that can be used to build a sort of mesh of applications that don’t feel like they have any clearly defined boundaries between them.
The problem with REST and why every “REST” app today is just a bespoke API serving JSON and not a walkable resource graph that any other application can automatically integrate with is because REST is actually really hard to get right. I feel like I understand it pretty well, but I’ve never actually built a decent REST api. And ultimately, REST only has value if lots of other apps are built with it because otherwise, you can’t integrate with them by automatically walking their resource graphs.
I think Elixir could actually solve this problem though.
Integration with third party services is the biggest PITA in professional web dev (next to the customer continuing to tell you that they cleared their cache when they 100% did NOT). This is because most APIs were built with a tight deadline, few resources, and even less design thought, so they generally suck. And there is no standard approach to integrating with a third-party service. If Elixir could enable something like REST but in a way that is actually feasible for the industry at large to adopt and get right, then it would make building and sharing web apps of any kind a lot easier for everyone.
Websockets have the ability to simplify these integrations by making the api malleable. If I could connect to a public websocket to integrate with a service and just send and listen for certain messages in a certain shape, I wouldn’t have to read through 10000 pages of poorly written user guide documentation or swagger api docs or write a parser for their whole resource tree. I wouldn’t have to bother with webhooks or some other kind of stateless event handling architecture. I would just need to know which subprotocol they use, how to authenticate if at all, and the shape of the one or two messages I care about for the app I’m building.
Websockets and HTTP{2|3} can’t create this kind of mesh of applications on their own though because making them reliable is just as hard as designing a proper REST api. This is where Elixir comes into the picture. The self-healing capabilities of the BEAM and the simple concurrency primitives in Elixir would make these usability and reliability problems feasible to solve for practical applications. If every integration was just a GenServer that sent and received messages over a websocket with a standard URL naming convention, then pretty much every third party integration would look almost exactly like this:
def start_link(opts) do
GenServer.start_link(StripeIntegration, %{}, opts)
end
def handle_info({:stripe_api, {:payment_approved, %StripePayment{} = payment}}, state) do
{:noreply, record_payment(state, payment)}
end
def handle_info({:stripe_api, msg_i_dont_care_about}, state) do
{:noreply, state}
end
The business logic for what you do with that integration would ofc be as complicated as it always was, but that’s the point. This would allow us to focus on actually doing something useful with the integrated service instead of spending 75% of the sprint figuring out how to get a %StripePayment{} struct into our service layer.
There have already been efforts to define specific subprotocols to enable these kinds of app-app communications such as wamp but ultimately, handling websockets in most languages ends up falling short due to the hidden difficulty just like REST did, so we need a language and tools that are capable of abstracting away the reliability aspects of it. Because in order for it to work as a universal integration protocol, it needs to be easy to use for everyone. Even that one guy on every team who deploys on Saturday. 
1