floscodes
flopetautschnig

It’s also important to clarify that this is not a bridge to Meshtastic or an integration with the Meshtastic application layer. It simply uses the Meshtastic protocol as a transport medium. RNS packets are encapsulated into Meshtastic frames, so from Reticulum’s perspective it’s just another interface.

2026-08-01 14:37:26 UTC

- reply

From my perspective, that dramatically lowers the barrier to entry. There are already thousands of Meshtastic devices in the wild. If those radios can be used as Reticulum interfaces without any firmware changes, Reticulum suddenly becomes much more accessible.

2026-07-31 03:15:59 UTC

- reply

…just another interface.

2026-07-31 03:08:40 UTC

- reply

Happy if you Check it out 😉

2026-07-30 18:00:10 UTC

- reply

2026-07-30 17:58:20 UTC

- reply

Of course, there are practical performance limitations. Meshtastic offers relatively low bandwidth, so large transfers will be slow. In my implementation I’ve also deliberately limited forwarding to a single Meshtastic rebroadcast (1 hop) to avoid overwhelming the Meshtastic mesh with high-volume Reticulum traffic. The goal is to make Reticulum available over existing Meshtastic infrastructure while still being a good citizen on the network.

2026-07-30 17:08:28 UTC

- reply

more accessible to a much larger community.

2026-07-30 17:07:26 UTC

- reply

One of the biggest advantages is that it could instantly give Reticulum access to the existing Meshtastic ecosystem and community.
The idea isn’t to replace Meshtastic or require people to flash different firmware. You simply leave the standard Meshtastic firmware on the radio and use it as a native Reticulum interface.
From my perspective, that dramatically lowers the barrier to entry. There are already thousands of Meshtastic devices in the wild. If those radios can be used as Reticulum interfaces without any firmware changes, Reticulum suddenly becomes much more accessible to a much larger community.

2026-07-30 14:32:31 UTC

- reply

The MeshtasticInterface is now available as a standalone Python file. If Reticulum is already installed, simply copy it into ~/.reticulum/interfaces and add the configuration.
👉 https://github.com/floscodes/RNS_MeshtasticInterface
#Reticulum #Meshtastic #LoRa #MeshNetworking #OpenSource

2026-07-30 09:27:19 UTC

I’ve added a Meshtastic Interface to a Reticulum fork. If anyone with a Meshtastic setup would be willing to test it and share feedback, I’d really appreciate it:
https://github.com/floscodes/Reticulum
Thank you!
@npub1ej5…f6k2 @npub142t…s6ue #meshtastic #reticulum #rns

2026-07-09 08:12:46 UTC

- reply

2026-07-09 08:11:48 UTC

- reply

@nprofile…0ef0 You said it yourself — people should be able to send tips in any way they want. I was thinking about it and so this is my proposal: an opt-in path for those who'd rather receive on-chain in their own wallet than via Lightning.

2026-07-08 13:24:57 UTC

- reply

🔥 Spark — a proposed Nostr extension for triggering native on-chain wallets directly from a profile. No Lightning, no receipt event: just a wallets array in Kind 0 metadata and a Kind 9736 request that hands off to your wallet extension or app via deep link.
PoC: https://floscodes.github.io/spark-poc/
Discussion: https://github.com/nostr-protocol/nips/issues/2387

2026-07-08 13:24:38 UTC

- reply

2026-07-08 13:21:33 UTC

- reply

You said it yourself — people should be able to send tips in any way they want. I was thinking about it and so this is my proposal: an opt-in path for those who'd rather receive on-chain in their own wallet than via Lightning. Doesn't touch Zaps or NIP-57 for anyone who's happy with those.
🔥 Spark — a proposed Nostr extension for triggering native on-chain wallets directly from a profile.
PoC: https://floscodes.github.io/spark-poc/
Discussion: https://github.com/nostr-protocol/nips/issues/2387
@nprofile…0ef0

2026-07-08 13:14:55 UTC

🔥 Spark — a proposed Nostr extension for triggering native on-chain wallets directly from a profile.
No Lightning, no receipt event: just a `wallets` array in Kind 0 metadata and a Kind 9736 request that hands off to your wallet extension or app via deep link. Chain-agnostic by design (BTC/XTM/SUI/ETH so far).
PoC: https://floscodes.github.io/spark-poc/
Discussion: https://github.com/nostr-protocol/nips/issues/2387
#nostrdev #tari #xtm #spark #zaps

2026-07-08 13:13:21 UTC

- reply

You said it yourself — people should be able to send tips in any way they want. I was thinking about it and so this is my proposal: an opt-in path for those who'd rather receive on-chain in their own wallet than via Lightning. Doesn't touch Zaps or NIP-57 for anyone who's happy with those.
🔥 Spark — a proposed Nostr extension for triggering native on-chain wallets directly from a profile.
No Lightning, no receipt event: just a `wallets` array in Kind 0 metadata and a Kind 9736 request that hands off to your wallet extension or app via deep link. Chain-agnostic by design (BTC/XTM/SUI/ETH so far).
PoC: https://floscodes.github.io/spark-poc/
Discussion: https://github.com/nostr-protocol/nips/issues/2387
@nprofile…0ef0

2026-06-21 09:37:14 UTC

- reply

Just dropping this here for #xtm

2026-06-21 07:17:27 UTC

- reply

Just introduced a design pivot for multi-asset zaps.
Shifting heavy crypto complexity from the client to native wallets using dynamic ⁠deeplink_templates⁠ in Kind 0. Keeps events tiny and clients asset-agnostic.
#nostrdev #tari #zaps #nip57

2026-06-20 17:04:14 UTC

- reply

2026-06-20 17:03:34 UTC

2026-06-18 20:19:15 UTC

- reply

Agreed, and thank you for the input! I really respect the focus on keeping the core simple. That freedom to choose our own tools and just see what works is precisely why I enjoy exploring this space.

2026-06-18 15:37:50 UTC

- reply

Dropping this here so @nprofile…n5fw can take a look. Would love to hear your thoughts on extending NIP-57 for non-LN sovereign assets!

2026-06-18 15:35:02 UTC

Idea: Let's bring native, on-chain zaps to Nostr without adding a single byte of profile metadata! 🪙
The trick: We can deterministically derive a Tari identity directly from our native Nostr keys. This allows us to extend NIP-57 and support sovereign P2P zaps natively in-client—no extra profile tags needed.
Just opened a proposal issue on GitHub. Let me know what you think: https://github.com/nostr-protocol/nips/issues/2387
#nostrdev #tari #zaps #nip57 @fiatjaf

2026-06-13 08:13:03 UTC

Do not stack. Put it on the heap instead 😜
https://blossom.primal.net/99239db819b837ffaf816a9693ce551ebb173bd7e873162995b6dc1789f40813.jpg

2026-06-12 08:16:16 UTC

- reply

🤣🤣👍🙌

2026-06-10 14:35:00 UTC

- reply

Word 🙌

2026-06-09 14:42:03 UTC

- reply

Absolutely 👍
#nevent1q…flaw

2026-06-08 13:04:48 UTC

- reply

Many people are tired of messaging apps that own your identity. So I authored a messenger client on the XMTP protocol that doesn't. No phone number, no server, no accounts — just a wallet key you control.
xmes.org | github.com/floscodes/xmes
#privacy #decentralized #rust #xmtp

2026-06-02 18:44:13 UTC

- reply

Glad it clicks! That’s exactly the idea — The Rust/WASM stack is holding up well so far. Would love to hear how it holds up in those midday threads — feedback from real use is what shapes the next iterations.

2026-06-01 20:37:15 UTC

- reply

Fair point — and it’s a tension worth naming. The wallet key is yours; the network layer underneath is still infrastructure you’re trusting. XMTP’s nodes are decentralized and the protocol is open, but you’re right that ‘owning your address’ isn’t the same as owning the whole stack. It’s a step, not the destination.

2026-06-01 20:35:52 UTC

- reply

Badge of honor accepted. No accidental bank memos — UI and wallet are strictly separated, so your financial chaos stays yours. And the Cargo builds are fast enough that you won’t even grow a full Rust-compilation beard. Looking forward to your first impressions. 🦀

2026-06-01 19:35:40 UTC

- reply

Absolutely.

2026-05-29 17:57:50 UTC

- reply

#privacy #decentralized #rust #xmtp

2026-05-29 17:56:53 UTC

- reply

No phone number, no server, no accounts — just a wallet key you control.

2026-05-29 17:56:33 UTC

- reply

No phone number, no server, no accounts — just a wallet key you control.
xmes.org | github.com/floscodes/xmes
#privacy #decentralized #rust #xmtp

2026-05-29 17:56:07 UTC

Many people are tired of messaging apps that own your identity. So I created a messenger client on the XMTP protocol that doesn’t.

2026-05-29 17:28:23 UTC

Many people are tired of messaging apps that own your identity. So I created a messenger client on the XMTP protocol that doesn't. No phone number, no server, no accounts — just a wallet key you control.
xmes.org | github.com/floscodes/xmes
#privacy #decentralized #rust #xmtp

2026-05-29 17:18:29 UTC

2026-05-29 17:12:16 UTC

2026-05-29 14:18:08 UTC

2026-05-29 14:17:14 UTC