#User == Node or not?

14 messages · Page 1 of 1 (latest)

radiant yoke
#

currently the protocol assume each node has one user and each user has one node.

This has problems for things like https://discord.com/channels/867578229534359593/1292983099704999986

I propose we add a virtual hop from the User to the Node

for is in the current system the hop chain would look like User -> Intermediate_Node -> Final_Recipient

in the new it would look like User -> User's_Node -> Intermediate_Node -> Final_Recipient

The way I believe that max hops work, that it set be the originating node, means it can just add one to it to account for the virtual hop.

If I was writing the firmware from scratch, I'd make is to make it accepts message over client protocol and handle them the same way as if it received them over LoRa, though I haven't dug into the firmware so don't know how big of a change that would require

wispy lily
#

I think it’s absolutely true that aside from specific wilderness scenarios, Meshtastic only really works if you have users on short range ground nodes entering the mesh which is actually comprised of a smaller number of optimally positioned nodes. More recognition of this and improving that use case would be worthwhile.

#

For example, the creation of a new type of node that acts as a gateway between some of the shorter range presets and a longer range one leveraging elevation and amplification.

#

The cellular phone network does this and a fair amount of that decision is likely due to physics

radiant yoke
wispy lily
#

No? This awareness of whether a roof node should do a hop-less repeat or a normal rebroadcast would depend on awareness of whether it was an originating user or not.

raven sonnet
#

I think (maybe?) both of you are discussing two aspects of the same problem?

@radiant yoke ‘s problem statement seems (to me) to be about the way a user is described today by meshtastic is not the human. It’s just a short name for the device.

To have a more flexible and natural hierarchy, the user could either be just ME or potentially my external device (Bills iPhone for example) and the short name is the device and the long name is just a longer name for the device. A USER could operate many devices (one to many user to device)

In theory meshtastic could be altered then to receive a DM to this new “user” on all devices tied to that user.

#

@wispy lily I think you are describing the use case of last hop to a client when there’s a roof node base station. My desktop unit isn’t seeing all the messages that the roof gets because of the additional hop.

How could we make special roles deliver locally all messages received at the roof node? This concept of a shared user would help. A second channel could help if it was lower power (to reduce noise on the rest of the mesh).

radiant yoke
radiant yoke
#

Here's little diagram, users would have their own meshtastic IDs separate from the node they are using; which would be used for stuff like telemetry and node management.

but yeah the node would have to relay messages over the virtual hop if it' destined to the user seen if they. thou it could just send all messages over the BT connection and allow the app to deal with it.

my idea was that it would use the current client protocol with just an enhancement for the client to send a meshtastic packet to the node to be handled like it was received over lora.

the thing you say macegr was talking about could be handled by
https://discord.com/channels/867578229534359593/1318619071830425692

graph.png
celest crest
#

I was pondering the same thing. You can make it so that your phone app creates a virtual? node in it, with its own node id, name, and keys. Then when you send a message from your phone the physical node just forwards it on without decrementing the hop count. It would mean that a person could have a single identity on the network and connect to whichever physical node happens to be available.

stray crown
#

I've been thinking along similar lines. My phone (me) ought to be a node, and my device should be a remote node that I administer, and that gets me from a Bluetooth (or WiFi or USB) connection to the mesh, onto a LoRa connection to the mesh.

#

A really nice aspect of this would be that I would be me, whichever of my devices I happen to be using at the time.

raven sonnet
#

I really like these ideas. There are some things that would be required to make it really useful. The physical user node needs to know its owners meshtastic node ID. and that all of the physical nodes owned by me should listen for direct message packets (not necessarily channel messages) and basically use a "store and forward" policy for them. That way you don't have to be connected and then you could get the message from any of your nodes. I would also like the phone client to be able to seemlessly connect to any of the nodes that are in BLE range, and pick up messages. That's a lot of change to ask for, but it would make the mesh a real messaging infrastructure.