Address book queries

[faragher]

Okay, so after close to a year of this, I might have something that could be helpful for newcomers. Since there's the capability for querying a network for paths, is it a good idea to generalize that to return a node's own identity (as an opt-in, like ping) in response to a non-routed broadcast?

Perhaps the most elegant solution is to add a status bit to an announce? Basically "My directory is empty, please help!" Any propagation node that sees it could return its own path/keys and propagate the announce as normal, removing the status bit. This ensures a lack of flooding of responses but proper propagation of the announce.

It does require a certain amount of implicit trust of that first propagation node, but since it's likely the node directly connected by hardware, there would've been some opt-in at that point.

An alternate mechanism is to pass the announce as-is, and any gateways that see it would respond with "I am online and ready to process your path requests."

If the gateway had an indexing system similar to the Amber Pages, that would allow a new user to jump in immediately without waiting for announces or blindly messaging peers to see if their connection works.

Am I missing a flaw in this concept?

[SebastianObi]

Some time ago, I also had the idea that application-specific optional data could be transferred in an announcement.
In a similar way to an lxmf message, there are the optional "fields" in which a dictionary can be transferred.

Since changing the announce data led to an incompatibility, Mark had discarded this idea.

Perhaps we could discuss again whether it makes sense to add an optional dictionary.

This could also be used to transmit a status byte such as user online/offline/contact me or similar. In some of my applications I simply transfer a msgpacked dictionary as announce data. If all applications know how the data should be decoded, it works of course.

[markqvist]

LXMF is a messaging protocol with specific goals. It seeks to provide realtime communication, but also work when large time delays in reachability are present, or when endpoints are never online at the same time. Therefore, the amount of application data that can be included in the actual Reticulum announces for LXMF destinations is intentionally very limited. This also helps protect against metadata leaks and profiling.

Having LXMF work over extremely slow mediums, currently sub 250 bits per second, is another reason for not including anything else than strictly necessary in the announces themselves. There will soon be some updates to LXMF that will use up the rest of the space I initially designed as reserved in the announces for LXMF, but it will not have anything to do with this though ;) It is more in line with enabling wider support for offline message transport, "sneakernet" style, and for optimising propagation node mesh topology.

This will not change, as I am not at all open to introducing feature creep into the LXMF system ;) But, you may be able to achieve what you want by simply using the fields part of an LXMF message. It was put there for exactly that reason. It's not called an extensible message system for nothing ;) If you want online/offline or other status info, you can simply transfer that as part of normal messages, or as "empty" messages with only the metadata. You are free to implement this however you want in your clients. If others like it, they might join your implementation and eventually form some sort of consensus.

By the way, @SebastianObi, I remember you talking about working on a forked version of Sideband, for your own organisation. Where is the source code for that currently posted? I'd love to have a look at that.

[markqvist]

Also, if you want a more real-time, "interrnet messenger/chat"-like experience, I wholeheartedly encourage you to just make up something new! You can always build a new application protocol (like LXMF, but tailored to your own needs) on top of Reticulum. I know it's not a two-day project, but it's a lot simpler to get up and running that if you were dealing with IP!

Then again, LXMF is pretty darned neat in many ways ;)

[SebastianObi]

Hello Mark,
Thank you for your interest in the further development of the fork of the Sideband app. The app is still private and is currently being prepared for release in spring 2024. As it is a private project with no further support, development is progressing slowly. The FDG would like to involve you - as it always has - in the closer development work of the Reticulum-based Free German Emergency Radio Network for spreading in DACHLI, but you left us in the past. We would therefore like to know in advance whether you are now open to cooperation without skepticism. That would make us happy!

Kind Regards, Sebastian

[markqvist]

but you left us in the past [etc,. etc,]

The what, now? Drop that rhetoric. I never "joined you" in the first place.

At one point, I politely informed some associates of your organisation that I would not comply with their stupid and unrealistic wishes and pseudo-demands for making destructive changes to the core concepts of Reticulum just to further their own personal and political interests.

They then got pretty miffed that I wasn't going to dance to their tune, and proceeded to act hysterically.

This kind of unproductive waste of time has me at the absolute limits of my patience towards this "FDG" - which has made nothing but demands, acted grandiose and entitled, and most importantly provided absolutely nothing of value back to the project.

If you want to echo that behaviour, I can assure you I will become very uncooperative towards you in about 4 nanoseconds.

If you, on the other hand, want to retain some semblance of cooperation from me, I'd advise you to kindly let me know the following:

• Why is the source code of your fork not publicly available right now?
• What is the latest commit of Sideband you have used code from?
• How are you ensuring the application is being distributed in accordance with the relevant license terms?
• Why did you delete this issue, that contained details of the app?

[SebastianObi]

It is a private project by people in a private club. It also has nothing to do with my account. That's why there is nothing public anywhere. Anyone who shares the same interests can join. I have used unclear words with "prepared for release in spring 2024". It is not the software that is planned to be published, instead it is information and documentation about the project. So that anyone with interest can join.

I will send you an e-mail later.
Any further discussion here would be in the wrong place.
I will no longer interrupt you by posts on github.

[markqvist]

I am assuming you are talking about this in the context of nomadnet, right? Since for Reticulum itself, the situation is basically a combination of that mostly not being necessary, and the necessary functionality already being implemented.

In terms of nomadnet, I've been thinking about it a bit myself, but never reached a conclusion. I've had this point sitting in my notes/todo for nomadnet for quite a while:

• Possibly a Search Local Nodes function
  • Needs "max search response frequency", "max depth" or something
  • Think about implications

So... Unfortunately I haven't actually done any of that thinking, and I invite anyone else that wants to do so to join in :)

I think it does make most sense as a sort of "search for local / semi-local / near nodes" type of thing.

[faragher]

Every use of someone else's system/data is an exercise in trust, but as multiple access points become available, decision and correlation between them becomes useful in vetting information.

And that's exactly my intent: onboarding new users. Generalizing this into a local node search is ideal in many ways, and I'm glad this was immediately pointed out to me. I generally dislike engineering solutions to training problems, but let's be honest, for the average user, things must be as easy as possible. It breaks my heart that somehow many kids with 24/7 access to smart phones have zero computer or technical skills. A triumph for UI, but no skills for wider use.

But I am a practical man, and I can complain about how I wish things were, or work with the way things are, and provide engineering solutions, even though leaving the options open is always, always the best way forward.

[markqvist]

A balanced approach is necessary, and part of the ethos of Reticulum. Requiring new users to actively think and learn something is a good thing. We need this, at large, to help regain technical literacy and agency, in a world dominated by technological feudalism.

We should not be building toys that 99% of people can just pick up and play with effortlessly; that already exists in nauseating quantities. But we should also not create something that is so conceptually contrived as to be impossible to grok!

If the user is forced to think and gain a new perspective or two in adapting to using systems based on Reticulum, that is not just acceptable, but in fact part of the what I am aiming for.

We solve nothing by giving people better tools, if they don't also get the means to understand them and make them their own. The artful execution of this lies in finding a middle way.

[faragher]

I agree that there needs to be balance, but don't necessarily agree about not being instantly accessible. However, it's a nuanced discussion, so I'm going to post a wall of text in the hopes I can explain my position, which is my style, apparently. :D

I love playing the old Dune board game with the right group of friends. It's dense, you spend days reading then digesting the rules, and you can get a great game out of it. I disagree when the simplified it, and the simplest games, like Diplomacy, fail without a good group of people. But finding people to play Dune with is a chore. Especially people you want to play with twice.

Many video games have a tutorial, hard or soft, to get new players on board. Dark Souls, known mostly for being hard and unfair (a very unfair generalization, it's demanding and very fair, but absolutely not unfair) starts by laying out how to do basically every action one step at a time. If the player can puzzle out "left thumb stick moves me" then every other action can be laid out to them one bite at a time. Until the end of the first stage when it basically lets go and tells you nothing. It's an incredibly deep set of systems people may not ever discover, but their hand is held, optionally, until they can navigate the world and discover for themselves.

Same with games like Metroid, which drip feed abilities and techniques to the player until they reach mastery. Hollow Knight deliberately leaves in exploits where a skilled player can bypass a lock if they know what they're doing. It rewards knowledge of the systems.

Tools aren't a game, but the accessibility is important. Take Sideband, which I find incredibly user friendly and intuitive. The basic abilities are on display and you can get up and running almost instantly. The two big things I'd want for true hand-holding purposes are having something on display immediately if the test net connection is well established, and telling people notifications only come from trusted addresses.

I need to run, so I'm going to wrap up quickly.

NomadNet is excellent, and I'd love offline documents but that's a matter of just not having enough time in the day to do everything.

The two solutions I currently favor for the "nobody's online" announce thing are the local net detection or a new version of EchoBot, GreetBot. Something a person could manually run on a network and would see an announce, check if it's ever seen the address before and respond with "Hi, I'm GreetBot. I saw your announce and I don't think I've seen you before. Your network connection is working properly, and you'll soon start to receive announces from other peers and nodes. You should only receive this message once. Welcome to the Test Net, and have fun! This mailbox is unmonitored."

Not ideal, not terrible, but another solution that fixes my concerns and does what Echobot was intended to do, but better.

Again, gotta run.

[faragher]

Okay, to put down the best conclusion I could come up with, from a programming viewpoint, I don't want:

import HelloWorld as HW
  HW.run()

This is ultimately useless as a tool for making tools.

I also don't want machine code, where you can do basically anything the hardware provides, but you may need to make your own bitmap fonts and blit to the screen memory to actually render anything. It's a large barrier.

I want one of the more accessible languages. Sure, Console.WriteLine() print(), and System.Diagnostics.Debug.Writeline() are all slightly different, but they're instantly recognizable and a "Hello World" program is recognizable and easy to modify. What about inputs? What about screen position? Is this only ASCII?

That's how I want Reticulum, Sideband, and NomadNet to be, ideally. My internal goal is to get someone set up and seeing nodes on the network in one try and just a few minutes. Then I want them to see the path forward and wonder "where can I go from here?"

I want a team to be able to scan a QR code, download an app, look at a sign, enter some numbers, and go do their thing. Actually running a telemetry system and making it functional doesn't need to be turnkey. A tool for making tools. I think we're very close, and I think we're on the same page, but I wanted to be clear. I'm not looking for Snapchat or whatever, I just want to get people feeling invested and curious ASAP.

[markqvist]

Totally agree on that approach! Sorry for not being more verbose in my answers to this, it's a very interesting topic and it needs discussing, but I'll have to wait with expanding more on it, since I don't have more time with internet connectivity now :)

See ya all some time in the new year :)