protocol VS electricui-embedded

We have already have a clear stack. there's Gitcoin Passport for sybil resistance, git (and wrappers like Radicle) for version control, Lit PKPs & Gelato for account abstraction, Farcaster/Orbis/Lens for social architecture, OpenStreetMaps for geographic markets, OPStack, etc.

These services exist outside of the protocol and depend on a few centralized and trusted authorities.

Another solution that is arguably more resistant to capture and censorship would be to use a blockchain to manage user name aliases - like Farcaster is doing with fnames.[1]

[1] https://github.com/farcasterxyz/protocol#22-farcaster-names

one XMPP server gets big and usernames get squatted and dealt with at the discretion of the server admin.

Only solution is something like how Farcaster does it

https://github.com/farcasterxyz/protocol#3-identity

That's sad to hear, but it makes total sense to shut down the server given its sensitive data, rather than hand it off to another person.

Mastodon/ActivityPub is a poor fit for a social network IMHO.

- Accounts should not be tied a single server and their continued maintenance.

- Private data and DMs should be end-to-end encrypted rather than entrusted with a single administrator.

- People don't want to self-host.

The core problem of a lot of social networks comes down to name aliasing, and who controls the name registry. In the case of nostr[1] this is not a problem because everything is using public keys. Another protocol is Farcaster[2] which plans to use a smart contract to maintain a name registry without requiring a single controller.

[1] https://github.com/nostr-protocol/nostr

[2] https://github.com/farcasterxyz/protocol

We have an MIT licensed protocol and Arduino library that makes it really easy to transfer data to the UI, and components for real-time line or scatter plots.

It includes an MIT licensed binary protocol that handles framing, checksums and multiple messageIDs. Standard C types are zero-configuration, just send them from hardware and the UI knows how to decode it. You can mark variables with some macros and get read/write capability in very little code. Assuming you're communicating over usb-serial, it should be very easy to get started. Here's the 'Arduino blinking led' firmware as an example.

We have an MIT licensed protocol and Arduino library, which provides framing, checksums, multiple messageIDs, query / set / call function behaviour, type information, ack packets, 1kB payload sizes by default and offset packets for sending larger data. There's a write up of the protocol here. I'm unsure how you've developed your stand alone program, but if you implement the 'host' side of the protocol, the Arduino library will take care of everything else.

If it's just the protocol you want, we have an open source, MIT licensed protocol available on GitHub. It comes with an Arduino library that you can install in a couple of clicks.

As a continuation of my other comment, Electric UI's binary protocol makes sending different data at different intervals pretty trivial. It's intended for serial comms, but of course can be sent over ethernet just as well.

It has an MIT licensed binary protocol that handles framing and checksums which works well over serial. There are several Arduino firmware examples in that repo.

While it is transport and protocol agnostic, it comes with a 'batteries included' binary protocol for serial comms to get up and running quickly. The protocol handles framing, multiple message IDs, acks and checksums.