Is trage communicatie beter dan geen communicatie?

Pagina: 1
Acties:

  • Sy0n
  • Registratie: December 2014
  • Laatst online: 02-02 17:12
Ik wil iets voorleggen als gedachte experiment. Geen productidee en ook niet “dit is de oplossing”, maar een idee waar ik al een tijd mee rondloop en waarvan ik me afvraag of het ergens hout snijdt.

Ik blijf hangen bij de vraag wat er nog kan werken als communicatie echt onder druk komt te staan. Niet bij een kleine storing, maar in een worst‑case scenario waarin internet en mobiele netwerken praktisch niet meer bruikbaar zijn. Tegelijk zou zo’n fallback zo laagdrempelig moeten zijn dat iedereen met een gewone smartphone ermee overweg kan, zonder voorbereiding of extra hardware.

Bij grote storingen zie je eigenlijk al een voorproefje van zo’n scenario. Communicatie valt dan niet volledig uit, maar wordt wel praktisch onbruikbaar: netwerken raken overbelast, berichten komen veel later aan of helemaal niet, en centrale infrastructuur wordt ineens een knelpunt. Dat patroon zie je terug bij drukke evenementen, landelijke storingen en andere situaties waarin het systeem tegen zijn grenzen loopt.

Mijn eerste gedachte ging richting mesh‑netwerken. Dat klinkt logisch, maar in de praktijk wordt het al snel complex. Routing, energieverbruik, schaalbaarheid, het vraagt veel van apparaten en gebruikers, en daarmee verdwijnt juist de eenvoud die je in zo’n noodscenario nodig hebt. Dat bracht me bij de vraag of het nog simpeler kan.

De kern van het idee is vrij rechttoe rechtaan. Stel je voor dat elke smartphone een kleine hoeveelheid korte tekstberichten kan bewaren. Geen media, geen chatgeschiedenis, alleen losse berichten. Wanneer twee mensen elkaar tegenkomen, wisselen hun telefoons die berichten uit. Daarna bewegen ze weer verder, ontmoeten anderen, en gebeurt hetzelfde opnieuw. Berichten verplaatsen zich zo letterlijk met mensen mee door een stad.

Dat is traag, en dat is ook precies de bedoeling. Als alles normaal werkt, is zo’n systeem nutteloos; dan is elk bestaand netwerk beter. Maar als bellen, data en zelfs SMS praktisch niet meer werken, wordt “een bericht dat later aankomt” ineens interessanter dan “een bericht dat nooit aankomt”.

Belangrijk daarbij is dat berichten zich niet onbeperkt verspreiden. Als elk bericht bij elke ontmoeting zou worden gekopieerd, raakt het systeem snel verstopt. Denk aan een supermarkt: twintig mensen, twintig kopieën, en binnen korte tijd draagt iedereen hetzelfde mee. Opslag raakt vol en relevante informatie verdwijnt tussen duplicaten.

In dit idee werkt dat anders. Elk bericht start met een klein aantal ‘doorgeef‑munten’. Zo’n munt hoort bij het bericht en kan maar op één plek tegelijk bestaan. Wanneer twee telefoons elkaar tegenkomen, kan het bericht één‑op‑één worden doorgegeven: het bericht en één munt verhuizen samen naar de volgende telefoon. De vorige drager is die munt kwijt.

Het gevolg is dat het bericht niet wordt vermenigvuldigd, maar zich verplaatst. Er zijn nooit meer actieve dragers dan het aantal munten waarmee het bericht begon. Die dragers kunnen het bericht blijven doorgeven zolang ze mensen tegenkomen, maar het aantal blijft gelijk. Het bericht groeit dus niet, het schuift alleen door.

Daardoor worden drukke plekken vanzelf minder belangrijk. Je hebt geen massa nodig, maar spreiding. Een paar mensen die zich door verschillende delen van de stad bewegen zijn waardevoller dan veel mensen die allemaal op dezelfde plek blijven. Het bericht volgt mobiliteit, niet dichtheid.

Wat mij hielp om dit te plaatsen, was terugdenken aan corona. Toen zag je ook dat drukke plekken vooral voor lokale verspreiding zorgden, maar dat de echte verspreiding tussen wijken en steden vooral kwam doordat een beperkt aantal mensen zich verplaatste: woon‑werkverkeer, OV, familiebezoek. Het ging minder om hoeveel mensen je zag, en meer om wie zich tussen groepen bewoog. In dit idee wordt datzelfde mechanisme benut, maar dan bewust afgeremd.

Dit betekent ook niet dat elk bericht automatisch bij iedereen terechtkomt. In de basis zijn er twee soorten. Sommige berichten zijn algemeen en bedoeld als informatie voor wie ze tegenkomt, zoals “hier is water beschikbaar”. Andere berichten zijn gericht aan één specifieke persoon, bijvoorbeeld een simpele check‑in; alleen die ontvanger krijgt daar een melding van. Voor iedereen anders blijft zo’n bericht onzichtbaar en wordt het hooguit tijdelijk meegedragen.

Identiteit speelt daarbij een beperkte rol. Elk toestel heeft een vaste digitale identiteit zodat je kunt zien dat berichten van dezelfde afzender komen, maar je weet niet automatisch wie daarachter zit. Als je dat wel wilt weten, gebeurt dat buiten het netwerk om, bijvoorbeeld door elkaar fysiek te ontmoeten en een soort token uit te wisselen. Voor onbekenden blijft communicatie bewust pseudoniem.

Dan blijft de vraag over misbruik en spam. Mijn gevoel is dat dit systeem spam niet perfect hoeft te blokkeren, maar het wel onaantrekkelijk maakt. Elk bericht kost ruimte, verdwijnt na verloop van tijd en kan zich maar beperkt verplaatsen. Er is geen garantie op bereik of zichtbaarheid. Als mensen besluiten een afzender niet meer door te geven, door de afzender bijvoorbeeld te blokeren, sterft zo’n bericht vanzelf uit.

Ik zie dit nadrukkelijk niet als chatapp, niet als realtime communicatiemiddel en niet als vervanging van bestaande netwerken. Het werkt slecht als mensen zich helemaal niet verplaatsen en het biedt geen garanties. Dat zijn geen bugs, maar grenzen van het idee.

Wat mij er vooral aan aanspreekt, is dat het volledig leunt op iets dat bijna altijd blijft bestaan: menselijke beweging. Geen masten, geen servers, geen centrale choke points. Geen belofte dat alles werkt, alleen de vraag of er iets kan blijven werken als veel andere dingen dat niet meer doen.

Ik ben benieuwd hoe hiernaar gekeken wordt. Zie ik fundamentele aannames over het hoofd? Zijn er voorbeelden waar dit soort ideeën in de praktijk juist faalden of werkten? Of is dit vooral een theoretisch idee dat weinig toevoegt?

  • g0tanks
  • Registratie: Oktober 2008
  • Laatst online: 20:06

g0tanks

Moderator CSA
Er zijn verschillende peer-to-peer chat apps die ongeveer doen wat jij beschrijft, zoals bijvoorbeeld Wikipedia: Bitchat

Het aantal 'hops' wordt typisch beperkt door een limiet van X aantal in te stellen, of berichten een maximale levensduur te geven.

Ultrawide gaming setup: AMD Ryzen 7 2700X | NVIDIA GeForce RTX 2080 | Dell Alienware AW3418DW


  • Sy0n
  • Registratie: December 2014
  • Laatst online: 02-02 17:12
g0tanks schreef op maandag 12 januari 2026 @ 22:44:
Er zijn verschillende peer-to-peer chat apps die ongeveer doen wat jij beschrijft, zoals bijvoorbeeld Wikipedia: Bitchat

Het aantal 'hops' wordt typisch beperkt door een limiet van X aantal in te stellen, of berichten een maximale levensduur te geven.
Wat ik daar lastig aan vind, is dat ze impliciet blijven uitgaan van een netwerk dat als netwerk moet blijven functioneren. Zodra je probeert dat op te schalen naar een hele stad, krijg je te maken met enorm veel nodes die continu in en uitvallen. Routing, discovery en het bijhouden van wie waar is wordt dan snel complex en fragiel, zeker als de dichtheid wisselt.

Het idee dat ik hier probeer te verkennen vertrekt juist vanuit het accepteren dat zo’n netwerk op stedelijke schaal eigenlijk niet goed te onderhouden is. In plaats van proberen alles verbonden te houden, laat je dat los en accepteer je dat berichten soms gewoon blijven liggen tot ze fysiek worden meegenomen naar een andere plek. Dat maakt het trager dan mesh-oplossingen, maar mogelijk robuuster zodra je voorbij kleine groepen of één locatie komt. Het is dus geen alternatief voor bestaande P2P-chatapps, maar een andere aanname over wat er nog kan werken als schaal en instabiliteit het netwerk zelf onderuit halen.

  • laurens0619
  • Registratie: Mei 2002
  • Laatst online: 20:03
Ik denk dat het een goed onderwerp is en veel mensen zich niet beseffen hoe groot de impact is als je communicatieloos bent. Het zit zo verweven in de basis.

Zelf vind ik meshtastic het mooiste want dat is echt peer to peer. Ik kwam er ook wel achter dat ik er niet het dorp ermee uit kwam, lijkt echt lokaal te zijn dus viel tegen

Wilde ik verder dan moest ik met meshcore aan de gang daarmee kom ik heel nl door maar nog steeds erg instabiel en onvoorspelbaar.

In afrika is geloof ik ooit een proef geweest met peer to peer gsm telefonie om veel dekking zonder masten te realiseren.

Zou mooi zijn als fabrikanten zoals apple zelf kwamen met het inbakken van zoiets in de telefoon. Een serverloos alternatief.
Eigenlijk zoals de satelliet modus in de laatste iphones, alleen dan op mesh gebaseerd.

Ik denk als apple dat inbakt je al best snel veel dekking kunt krijgen

Hier nog leuk artikel
https://medium.com/coding...ommunication-3187c2df995d

[ Voor 9% gewijzigd door laurens0619 op 12-01-2026 23:36 ]

CISSP! Drop your encryption keys!


  • Koekstra
  • Registratie: November 2012
  • Niet online
Ik zie een 2-tal uitdagingen, namelijk hoe voorkom je dat de berichten 'rond blijven gaan' in een menigte? En hoe zorg je er voor dat mensen actief hun telefoon opladen en mee nemen?

Dan zou het peer-to-peer verhaal primair reden moeten zijn om dit te doen, maar ik twijfel of dit mensen over de streep trekt..

  • Sy0n
  • Registratie: December 2014
  • Laatst online: 02-02 17:12
laurens0619 schreef op maandag 12 januari 2026 @ 23:29:
Zou mooi zijn als fabrikanten zoals apple zelf kwamen met het inbakken van zoiets in de telefoon. Een serverloos alternatief.
Eigenlijk zoals de satelliet modus in de laatste iphones, alleen dan op mesh gebaseerd.

Ik denk als apple dat inbakt je al best snel veel dekking kunt krijgen
Dat verbaast mij ook. Als zoiets op OS-niveau zou bestaan en gewoon passief meedraait, verandert alles. Dan is het geen app meer waarvoor je adoptie nodig hebt, maar een eigenschap van het toestel zelf, vergelijkbaar met hoe AirTags via bestaande iPhones werken.

Apple laat met AirTags en de satelliet-SOS-functie zien dat ze technisch prima in staat zijn om communicatie buiten het klassieke netwerk om te doen. Als zo’n mechanisme standaard in alle iPhones zou zitten, heb je op stedelijke schaal vrijwel automatisch dekking.

Tegelijk snap ik wel waarom fabrikanten hier terughoudend in zijn: batterij, privacy, misbruik en aansprakelijkheid spelen allemaal mee. Maar juist als fallback voelt het alsof hier nog veel onbenut potentieel zit.

  • Sy0n
  • Registratie: December 2014
  • Laatst online: 02-02 17:12
Koekstra schreef op maandag 12 januari 2026 @ 23:40:
hoe voorkom je dat de berichten 'rond blijven gaan' in een menigte?
Dat is inderdaad een risico als je berichten onbeperkt kopieert. In het idee zoals ik het voor me zie gebeurt dat juist niet. Berichten worden niet eindeloos vermenigvuldigd, maar verplaatsen zich met een beperkt aantal “dragers”. In een drukke menigte zorgt dat er niet voor dat het bericht explodeert, maar juist dat het snel vastloopt: dezelfde mensen blijven elkaar tegenkomen en het bericht komt niet verder. Dat is geen bug maar een eigenschap. Het systeem heeft meer aan spreiding dan aan dichtheid; een paar mensen die zich verplaatsen tussen groepen zijn waardevoller dan honderd mensen op één plek.
Koekstra schreef op maandag 12 januari 2026 @ 23:40:
hoe zorg je er voor dat mensen actief hun telefoon opladen en mee nemen?
Ik denk niet dat dit werkt als je mensen vraagt dit actief te doen “voor het netwerk”. Dat trekt inderdaad niemand over de streep. De enige realistische reden is dat het apparaat er toch al is en de functie passief meedraait. Het peer-to-peer aspect is dan geen doel op zich, maar een bijwerking van iets dat mensen sowieso bij zich hebben: hun telefoon. Vergelijk het een beetje met hoe telefoons nu ook niet bewust “meedoen” aan het mobiele netwerk; ze zijn gewoon aan.

Daarom zou het ook mooi zijn als fabrikanten een dergelijke oplossing native zouden implementeren.

  • Sy0n
  • Registratie: December 2014
  • Laatst online: 02-02 17:12
Kleine update: ik heb dit idee inmiddels ook eens door een simpele simulatie gehaald, vooral om te checken of het niet compleet losstaat van de werkelijkheid. Niet als bewijs, maar als sanity check op de aannames.

Belangrijk om vooraf te zeggen: de simulatie start altijd met één toestel. Er worden geen grote aantallen dragers vooraf aangenomen. Extra dragers ontstaan alleen als mensen elkaar daadwerkelijk tegenkomen. Wat adaptief groeit is alleen een bovengrens: hoeveel gelijktijdige dragers een bericht maximaal mag hebben.

De aannames die ik daarbij heb gedaan (bewust simpel gehouden):
  • Stad van ~160.000 inwoners (orde Enschede).
  • Alleen een deel van de mensen is op een moment actief en onderweg; dat varieert per uur (’s nachts vrijwel niets, overdag duidelijk meer)
  • Per drager gemiddeld zo’n 10–15 “kansen per uur” om dicht genoeg bij iemand te komen voor een uitwisseling (denk supermarkt, OV, wachtrij)
  • Niet elke kans lukt: ik ga uit van ~30% kans dat een daadwerkelijke uitwisseling slaagt (OS-beperkingen, timing, ruis)
  • Geen kaart, geen vaste routes, geen kennis van waar iemand is; ontmoetingen zijn volledig lokaal en toevallig
Voor algemene berichten heb ik de adaptieve limiet iets ruimer gezet:
  • startlimiet 25
  • elk uur verdubbelen
  • met een maximum van 5000 gelijktijdige dragers.
Dat klinkt hoog, maar nog steeds geldt: die limiet wordt alleen bereikt als er genoeg echte ontmoetingen plaatsvinden. Er wordt niets “bijgeschakeld”.

Gerichte berichten (1-op-1, met bevestiging)
Met deze aannames lukt het vrijwel altijd om de ontvanger binnen 24 uur te bereiken. Dat gebeurt meestal niet snel: vaak pas na enkele uren. Als je ook wilt weten dat het bericht is aangekomen (via een ACK terug), ben je doorgaans nog een paar uur verder. In totaal zit je dan vaak ergens rond de 8 tot 12 uur voordat de afzender het zeker weet.

Dat voelt traag, maar dat is ook precies de trade-off: zonder netwerk koop je bereik met tijd. Wat ook duidelijk wordt: de bevestiging terug is structureel lastiger dan het eerste bericht. Twee keer een gerichte overdracht op stedelijke schaal zonder infrastructuur blijft zwaar.

Algemene berichten (bereik)
Voor algemene berichten heb ik niet gekeken naar “delivery”, maar naar bereik: hoeveel unieke mensen krijgen het bericht binnen 24 uur te zien.

Met bovenstaande aannames komt het bereik grofweg uit op 80–85% van de stad binnen een dag. Dat groeit geleidelijk, vooral overdag wanneer er meer beweging is. De resultaten zijn vrij stabiel tussen runs; het lijkt dus geen kwestie van gelukstreffers.

Ook hier geldt: er ontstaat geen netwerk. Het bericht beweegt mee zolang mensen bewegen, en dooft vanzelf uit als dat niet meer gebeurt.

Wat ik hier zelf uit haal
Voor mij onderstreept dit vooral dat het onderscheid scherp blijft. Voor chat, interactie of garanties is dit geen geschikt model. Maar voor algemene noodinformatie of grove signalering lijkt het verrassend robuust, juist omdat het weinig probeert te regelen.

Nogmaals: dit is geen claim dat “dit werkt”, maar een poging om gevoel en aannames iets beter te kwantificeren. Ik hoor graag waar jullie denken dat deze aannames te optimistisch zijn, of juist onnodig streng. Ik ben zelf geen data-expert of statisticus, maar gewoon een programmeur die geprobeerd heeft het idee zo eerlijk mogelijk te benaderen :P

  • Sissors
  • Registratie: Mei 2005
  • Niet online
Waarom zou communicatie van A naar B structureel sneller gaan dan van B naar A, waarbij die verder gewoon identiek zijn in het grotere geheel?

Maar goed, om je topic titel is natuurlijk een enorme inkopper: Natuurlijk is dat beter. En tot helemaal niet zo lang geleden was trage communicatie (de post) gewoon de standaard. Maar het probleem blijft dat zulke mesh netwerken absoluut niet schalen, één groot privacy risico zijn, zwaar misbruikt zullen worden als ze populair zijn, etc.

Om er een paar uit te pakken:
met een maximum van 5000 gelijktijdige dragers.
Hoe zou dit werken? Als mijn telefoon een bericht heeft, geeft hij het alleen door als er niet meer dan 4999 andere telefoons al dat bericht hebben? En hoe weet mijn telefoon hoeveel andere dat bericht hebben? Dat weet ie niet, en dus blijft hij het rondsturen aan iedereen. Het enige wat daar tegen helpt zijn hop-limieten, en die zal je nodig hebben, maar met realistische limieten beperk je natuurlijk sterk hoe ver een bericht komt. En dan wil je niet tot hij eerst een hop naar de buurvrouw doet, dan naar haar zoon, dan naar zijn vriendje, etc. Nee je wil dat hij zo snel mogelijk naar iemand die ver reist gaat, en daarom heeft het echte internet (en UPS ook), een hierarchie zodat het zo snel mogelijk naar grote kanalen gaat.
Voor algemene berichten heb ik niet gekeken naar “delivery”, maar naar bereik: hoeveel unieke mensen krijgen het bericht binnen 24 uur te zien.

Met bovenstaande aannames komt het bereik grofweg uit op 80–85% van de stad binnen een dag. Dat groeit geleidelijk, vooral overdag wanneer er meer beweging is. De resultaten zijn vrij stabiel tussen runs; het lijkt dus geen kwestie van gelukstreffers.
Even los ervan dat je resultaten stabiel zijn vanwege de statistiek waar je voor hebt gekozen, maar dit is direct het probleem: Nu kan elke random idioot naar 80-85% van de mensen in een stad een bericht sturen. Dat gaat allemaal misbruik opleveren. Los van dat de fabrikanten daar sowieso niet op zitten te wachten, gaat de EU eisen dat die er wat aan doen, etc.

  • cannibal
  • Registratie: Maart 2001
  • Laatst online: 05-02 10:34
Zoals Sissors al zei, hoe weet een node (telefoon) wat de state is van het bericht?
Zo'n protocol moet alles maar blijven doorgeven, maar elke node is eigenlijk stateless, het enige wat je hebt is idd een hop-limiet.

Maar het bericht weet niet op hoeveel nodes het aanwezig is, het weet niet of het al aangekomen is bij de ontvanger en kan stoppen met doorgeven. Dus kom je weer bij de hoplimieten en in een drukke stad ga je die dan wel redelijk vlug bereiken. Of je moet ook iets van een max-age hebben, maar dat haalt dan de reliability (voor ontvangst) ook weer heel snel naar beneden.

  • ouweklimgeit
  • Registratie: Juni 2014
  • Niet online
laurens0619 schreef op maandag 12 januari 2026 @ 23:29:
Zelf vind ik meshtastic het mooiste want dat is echt peer to peer. Ik kwam er ook wel achter dat ik er niet het dorp ermee uit kwam, lijkt echt lokaal te zijn dus viel tegen

Wilde ik verder dan moest ik met meshcore aan de gang daarmee kom ik heel nl door maar nog steeds erg instabiel en onvoorspelbaar.
De ellende van Meshtastic is dat het gebaseerd is op flood-routing. Zodra je iets teveel nodes hebt dan raakt alles overbelast en komt niet meer over. Ook de hop-limit (die standaard op 3 staat) zorgt ervoor dat je berichten nooit ver op de mesh komen, helemaal als een paar personen een slecht geplaatste node als Router instellen.

In onze regio zijn we een paar maanden allemaal overgestapt op Meshcore en we bereiken Berlijn in 3 hops. De rest van Nederland is haalbaar, soms met 20 hops, maar berichten komen vaak probleemloos over van oost naar west en noord naar zuid. Voornaamste reden is dat de nodes leren wat de beste route is, het bericht gaat dus echt van repeater naar repeater totdat de ontvanger bereikt is.

  • shure-fan
  • Registratie: Maart 2002
  • Laatst online: 19:39
Als je echt offgrid wilt gaan, denk ik dat je moet denken aan meshtastic, of starlink in standby modus,

Of het oprichten van een point to (multi) point wifi netwerk en zelf services hosten,
Daarnaast het gebruik van pmr 446 portofoons

Voip enthousiastelling, Liever een kabel dan wifi


  • Muismat1991
  • Registratie: April 2016
  • Laatst online: 14:54
Sorry, maar ik moet deze even toevoegen.

Een RFC die specifiek is geschreven om communicatie te omschrijven in het geval dat het niet wired of wireless mogelijk is.

https://www.rfc-editor.org/rfc/rfc1149

En mocht je nog QoS willen inbouwen:

https://www.rfc-editor.org/rfc/rfc2549

[ Voor 5% gewijzigd door Muismat1991 op 13-01-2026 11:15 ]


  • Sy0n
  • Registratie: December 2014
  • Laatst online: 02-02 17:12
Sissors schreef op dinsdag 13 januari 2026 @ 09:58:
Waarom zou communicatie van A naar B structureel sneller gaan dan van B naar A, waarbij die verder gewoon identiek zijn in het grotere geheel?
Dat verschil komt denk ik vooral door een beperking in mijn simulatie en niet zozeer door het onderliggende idee. In de simulatie geef ik elk bericht een TTL van 24 uur op basis van een creation timestamp. Zodra die TTL verloopt, wordt het bericht lokaal verwijderd en ook niet meer doorgestuurd. De simulatie kijkt dus alleen naar wat er in die eerste 24 uur gebeurt. In dat licht is het logisch dat reacties van B naar A statistisch minder vaak aankomen dan het oorspronkelijke bericht van A naar B.
Sissors schreef op dinsdag 13 januari 2026 @ 09:58:
Hoe zou dit werken? Als mijn telefoon een bericht heeft, geeft hij het alleen door als er niet meer dan 4999 andere telefoons al dat bericht hebben? En hoe weet mijn telefoon hoeveel andere dat bericht hebben?
Dat punt herken ik, en daar zit inderdaad een fundamenteel probleem bij klassieke flood-based meshes: een node weet niets over de globale state. Hij weet niet hoeveel andere nodes het bericht al hebben gezien en weet ook niet of de ontvanger het al ontvangen heeft. Zonder aanvullende mechanismen blijft zo’n bericht dus eindeloos rondgaan, totdat een hop-limiet of max-age wordt bereikt.

Mijn idee was daarom om niet te werken met “kennis van de state”, maar met een vooraf bepaald budget per bericht.

Concreet: elk bericht krijgt bij creatie een initiële token count, bijvoorbeeld 5. Dat betekent dat de verzendende node (A) het bericht naar maximaal 5 andere nodes mag doorsturen. Die vijf ontvangers hebben vervolgens elk nog 1 token, wat inhoudt dat zij het bericht nog één keer mogen doorsturen naar een andere node.

Op basis van de creation time van het bericht wordt die token count bijvoorbeeld elk uur verdubbeld, totdat de TTL van het bericht is bereikt of een vooraf ingestelde bovengrens. Op die manier kun je lokaal bepalen hoeveel keer een bericht maximaal mag worden doorgestuurd, zonder dat een node hoeft te weten hoeveel andere nodes het bericht al hebben. Het resultaat is geen onbeperkte flood, maar een gelimiteerde exponentiële verspreiding door het netwerk.
cannibal schreef op dinsdag 13 januari 2026 @ 10:27:
Zoals Sissors al zei, hoe weet een node (telefoon) wat de state is van het bericht?
Klopt, en dat weet hij dus ook niet. Het idee is juist om die globale state niet nodig te hebben. De enige informatie die een node gebruikt is wat er in het bericht zelf zit: creation time, TTL en het resterende token-budget. Dat lost niet alles op, maar voorkomt wel dat elk bericht onbeperkt blijft circuleren.
Sissors schreef op dinsdag 13 januari 2026 @ 09:58:
Nu kan elke random idioot naar 80–85% van de mensen in een stad een bericht sturen. Dat gaat allemaal misbruik opleveren.
Daar ben ik het mee eens. In deze vorm is dit misbruikgevoelig en waarschijnlijk ook politiek en juridisch onhoudbaar. Daarom denk ik dat een realistischer richting zou zijn om dit niet als broadcast-achtig systeem te zien, maar vooral te beperken tot 1-op-1 communicatie. Bijvoorbeeld door vooraf contact toe te voegen via het uitwisselen van public keys, zodat je alleen berichten van bekende verzenders kan ontvangen. Dat haalt een groot deel van het spam en abuse-probleem weg, al introduceert het natuurlijk weer andere beperkingen.
shure-fan schreef op dinsdag 13 januari 2026 @ 10:59:
Als je echt offgrid wilt gaan, denk ik dat je moet denken aan meshtastic, of starlink in standby modus…
Ik begrijp dat die alternatieven bestaan, en technisch zijn ze ook logisch. Alleen bij vrijwel al deze oplossingen heb je dedicated hardware nodig, of een setup die voor veel mensen simpelweg te ingewikkeld is. De instap is hoog, zeker voor iemand die niet technisch is.

Dat is voor mij juist het interessante aan smartphones: bijna iedereen heeft er al één, en bijna iedereen weet hoe hij er een simpel bericht mee verstuurt. Dat maakt ze, ondanks alle technische beperkingen, een interessant uitgangspunt om te onderzoeken waar de grenzen écht liggen.

[ Voor 0% gewijzigd door Sy0n op 13-01-2026 11:22 . Reden: typo ]


  • laurens0619
  • Registratie: Mei 2002
  • Laatst online: 20:03
@Sy0n
Heb je die medium.com link gelezen die ik postte?
Daar is ook in te lezen dat grote partijen zoals apple,android wss ook ermee bezig zijn :)

CISSP! Drop your encryption keys!


  • Sissors
  • Registratie: Mei 2005
  • Niet online
laurens0619 schreef op dinsdag 13 januari 2026 @ 11:49:
@Sy0n
Heb je die medium.com link gelezen die ik postte?
Daar is ook in te lezen dat grote partijen zoals apple,android wss ook ermee bezig zijn :)
De stap van: "Google bouwt bluetooth file sharing in", naar "Google is waarschijnlijk bezig met grootschalige mesh netwerken maken met Android telefoons", is nogal een stap.

Het probleem blijft simpelweg dat mesh niet schaalt. En doordat een SMSje oid zo verschrikkelijk weinig data kost vergeleken met een video stream oid waar onze telefoons voor gemaakt zijn, kan je best een eind komen met iets wat niet schaalt. Maar het blijft dat het allemaal exponentieel groeit.

En daar komt bovenop de privacy issues. En dan heb ik het niet (alleen) over de berichten. Je wil dat je telefoon weet of een bericht al gestuurd is naar een andere telefoon. Maar daarvoor moet die andere telefoon een unieke ID delen die niet veranderd. En wordt daarmee dus veel makkelijker te tracken.

  • Sy0n
  • Registratie: December 2014
  • Laatst online: 02-02 17:12
Sissors schreef op dinsdag 13 januari 2026 @ 11:56:
[...]
En daar komt bovenop de privacy issues. En dan heb ik het niet (alleen) over de berichten. Je wil dat je telefoon weet of een bericht al gestuurd is naar een andere telefoon. Maar daarvoor moet die andere telefoon een unieke ID delen die niet veranderd. En wordt daarmee dus veel makkelijker te tracken.
Het privacy-argument gaat uit van een verkeerde aanname. Je hoeft niet te weten dat het hetzelfde apparaat is via een vaste identiteit. Je hoeft alleen te voorkomen dat je binnen korte tijd hetzelfde bericht opnieuw aanbiedt. Dat kan zonder langdurige of trackbare ID’s.

Dit is exact hoe de corona-contacttracing werkte. Daar werden geen vaste device-ID’s gebruikt, maar tijdelijke, roterende identifiers. Telefoons wisten niet “dit is dezelfde persoon als eerder”, maar alleen “deze tijdelijke ID heb ik recent gezien”. Die informatie was lokaal en tijdgebonden, waardoor tracking over langere tijd niet mogelijk was (zie Apple/Google Exposure Notification en DP-3T)

Een mesh-bericht zou hier hetzelfde kunnen werken. Bij een ontmoeting wissel je een tijdelijke identifier uit en onthoud je lokaal, per bericht, dat je dit bericht al hebt aangeboden. Kom je iemand kort daarna opnieuw tegen, dan stuur je het niet opnieuw. Na ID-rotatie is het bewust een nieuw contact; dat is geen privacyprobleem en functioneel geen ramp, omdat TTL en tokenbudget de verspreiding begrenzen.

De echte uitdaging zit in adressering: hoe herken je voor wie een bericht bedoeld is. In theorie kun je proberen berichten met hetzelfde doel-ID te onderscheppen, maar door de store-and-forward aard van het netwerk is dat praktisch lastig en tijdrovend.

Daarnaast speelt context mee. In noodsituaties kan bereikbaarheid belangrijker zijn dan maximale privacy. Dat zie je ook bij radioverbindingen zoals 27MC, waar iedereen kan meeluisteren, maar communicatie toch wordt geaccepteerd. Dit soort store-and-forward concepten zit conceptueel dichter bij dat model dan bij moderne, identiteit-gedreven chatapps.

[ Voor 0% gewijzigd door Sy0n op 13-01-2026 13:07 . Reden: Iets duidelijkere verwoording ]


  • Jiangtao.L
  • Registratie: Mei 2025
  • Laatst online: 24-01 15:41
Een bericht wat later aankomt is niet per definitie beter dan een bericht wat helemaal niet aankomt, en al helemaal niet in een noodsenario. Als ik via een walkie-talkie, radio of via speakers iets hoor dan is dat actueel, een bericht via zo 'systeem' is misschien al dagen oud, en dan krijg je berichten waarbij dus niet weet of ze nog valide zijn. Niet iets wat je juist in een noodsituatie wilt hebben.

  • RappeDoper
  • Registratie: Augustus 2019
  • Laatst online: 03-02 15:01
Wat is nu precies je doel? Want je topictitel gaat over het definieren van een behoefte, maar de inhoud gaat al over een technische oplossing.

In situaties van uitgevallen gebruikelijke communicatienetwerken kan het zijn dat ik snelheid niet belangrijk vind, maar dat ik het wel belangrijk vind dat het secuur gebeurt bovenal dat ik kan vertrouwen (of wéten) dat het aankomt. Dus als je dan met een oplossing komt die zowel traag is als geen garantie geeft op aankomst, zou ik afhaken.

  • Sissors
  • Registratie: Mei 2005
  • Niet online
Sy0n schreef op dinsdag 13 januari 2026 @ 12:57:
[...]

Dit is exact hoe de corona-contacttracing werkte. Daar werden geen vaste device-ID’s gebruikt, maar tijdelijke, roterende identifiers. Telefoons wisten niet “dit is dezelfde persoon als eerder”, maar alleen “deze tijdelijke ID heb ik recent gezien”. Die informatie was lokaal en tijdgebonden, waardoor tracking over langere tijd niet mogelijk was (zie Apple/Google Exposure Notification en DP-3T)
Het standaard Bluetooth interval, waarbij ik aanneem dat ze daar ook zoiets hebben gebruikt, roteert elke 15 minuten. Als je een uur bij iemand die achteraf Corona bleek te hebben was, had je 4 identifiers gehad van diegene, was het via een centrale server gestuurd dat die identifiers corona hadden, en dan had je 4x Corona :P . Iets serieuzer, dan wist je dus dat je Corona risico had, of je nou 1x of 4x een unieke ID had veranderde weinig, misschien zelfs wel nuttig voor de kansberekening.

Maar dit is een fundamenteel andere use case. Ik wil een bericht versturen naar mijn hardloop buddy aan andere kant van de stad. Dus ik verstuur via het mesh netwerk. Die forward het aan mijn partner, want die zit naast mij op de bank. 15 minuten later krijgt die telefoon een nieuw uniek ID, en hij forward het again. Fastforward een paar uur, en hij vindt dat hij het wel vaak genoeg geforward heeft, ondanks dat het bericht nog steeds hemelsbreedt niet verder dan 2m is gekomen. En tegelijkertijd doe de telefoon van mijn partner hetzelfde, en het bericht is nooit mijn huis uit gekomen. Nu zou je wel wat kunnen implementeren dat diegene zegt dat het bericht al bekend is bijvoorbeeld, en het dan niet als een forward telt, maar het genereert op zijn minst een hele hoop extra verkeer. Want dit voorbeeld heb ik 1 berichtje van mezelf gestuurt. Maar wat als ik nu net thuis kom van de boodschappen doen, ik heb 1000 nieuwe berichten, en die gaan de telefoons steeds aan de ander vragen of ze die al hebben.
Daarnaast speelt context mee. In noodsituaties kan bereikbaarheid belangrijker zijn dan maximale privacy. Dat zie je ook bij radioverbindingen zoals 27MC, waar iedereen kan meeluisteren, maar communicatie toch wordt geaccepteerd. Dit soort store-and-forward concepten zit conceptueel dichter bij dat model dan bij moderne, identiteit-gedreven chatapps.
Ja maar als het niet altijd draait, en je moet het eerst handmatig aanzetten in een noodsituatie, hoeveel doen het, en alsnog hoeveel gaan ermee spammen?

  • mash_man02
  • Registratie: April 2014
  • Laatst online: 05-02 15:01
Er zijn wel organisaties die zich daar mee bezig houden.

Bijvoorbeeld dares.nl

Asus X570-E AMD ryzen 5800x3D 64Gb Sapphire 7900xtx X-vapor nitro+

Pagina: 1