permissionlesstech/bitchat-android
1
0
Fork 0
mirror of https://github.com/permissionlesstech/bitchat-android.git synced 2026-07-25 23:25:20 +00:00
Code Issues Packages Projects Releases Wiki Activity

add to spec

Browse Source
This commit is contained in:
callebtc
2025-09-19 22:40:38 +02:00
parent b60c0da1da
commit 94fbadb570
1 changed files with 7 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/SOURCE_ROUTING.md
+4 -2
View File
@@ -40,11 +40,13 @@ Unknown flags are ignored by older implementations (they will simply not see a r
When receiving a packet that is not addressed to you: When receiving a packet that is not addressed to you:
1) If `HAS_ROUTE` is not set, or the route is empty, relay using your normal broadcast logic (subject to TTL/probability policies). 1) If `HAS_ROUTE` is not set, or the route is empty, relay using your normal broadcast logic (subject to TTL/probability policies).
2) If `HAS_ROUTE` is set and your peer ID appears at index `i` in the hop list: 2) If `HAS_ROUTE` is set:
- **Route Sanity Check**: Before processing, the relay **MUST** validate the route. If the route contains duplicate hops (i.e., the same peer ID appears more than once), the packet **MUST** be dropped to prevent loops.
- If your peer ID appears at index `i` in the hop list:
- If there is a next hop at `i+1`, attempt a targeted unicast to that next hop if you have a direct connection to it. - If there is a next hop at `i+1`, attempt a targeted unicast to that next hop if you have a direct connection to it.
- If successful, do NOT broadcast this packet further. - If successful, do NOT broadcast this packet further.
- If not directly connected (or the send fails), fall back to broadcast relaying. - If not directly connected (or the send fails), fall back to broadcast relaying.
- If you are the last hop (no `i+1`), proceed with standard handling (e.g., if not addressed to you, do not relay further). - If you are the last hop (no `i+1`), the packet has reached the end of its explicit route. The relay should then attempt to deliver it to the final `recipientID` if directly connected, but SHOULD NOT relay it further as a broadcast.
TTL handling remains unchanged: relays decrement TTL by 1 before forwarding (whether targeted or broadcast). If TTL reaches 0, do not relay. TTL handling remains unchanged: relays decrement TTL by 1 before forwarding (whether targeted or broadcast). If TTL reaches 0, do not relay.