# How should group destinations across multiple hops function (and why they could be really powerful)

_General · started by welo on Sun, Jun 21, 2026 9:00 AM_

Tags: Discussion

---

## Original post

**welo** · Sun, Jun 21, 2026 9:00 AM

The manual is pretty light on details about this other than this line "When private communication between two or more endpoints is needed. Supports multiple hops indirectly, but must first be established through a single destination.", I think it means that you have to request for the symmetric key first from the destination but it isn't that clear and there's not much discussion about this anywhere so here's how I imagine group destinations could work

### Why I think group destinations could be really powerful

Now I will make the assumption that transport nodes duplicate group packets only as much as necessary for every downstream client that has the symmetrically key to get a packet. If a transport node has 4 direct connections that want a group packet then it obviously duplicates it but that if a transport is connected to 5 transport nodes and it receives a group packet whose destinations' pathing is through 3 of them, the packet will be duplicated and sent to those 3 transport nodes.

This basically means that a group destination acts as a single destination when there is only one recipient and as announcement if everyone is a recipient. Obviously those are non useful extremes but they are to illustrate a point that anything in between would work fine. The exact mechanism of how a transport node would know where to send packets and whatever will probably be big discussion in the thread below but we'll go with this assumption for now.

LXMF group chats or anything similar are fine examples of using symmetric keys but at the end of the day you could do that with single destinations without any issue, hell that's what every single group chat on the normal internet does, it individually sends data to every user in a group chat and the overhead is minor if inefficient

The usecase I'm more excited for would be something more akin to radio/audio/video stream. The reason for this is bandwidth. Streaming content just does not scale on the regular internet, sending 10000 copies of the same 1080p video stream is not doable unless you are a giant cloud server, so people are forced to rely on these services. But you aren't sending 10000 different unique streams of data, only one of them that needs to reach 10000 different people. If you could send the same packets to those 10000 people then you only have to send the data into the network once then this scales infinitely with no issue, and that's exactly what I think group destinations could provide.

Infact group destinations could lower the load on the network for this kind of application, specially for the nodes directly connected to the server that you are streaming content from because instead of having to carry many copies of the same data wasting bandwidth, they just carry one copy and then duplicate it to upstream transport nodes when necessary. The load is spread across the entire network instead localised but only if other clients actually want data, and if only a few people want the stream then the data doesn't floodfill to every single transport node, but only to where it is needed. Only bit that might not scale is the fact the stream server would need a way of sending the symmetric key to any client that asks for it but that's a few packets at worst.

---