How to create an OUT destination from remote info provided to request handler

[ThomasFreedman]

Forgive me if this is obvious but I've been away for 2 weeks and I can't see how to do this.

app A announces, app B then creates a link to app A and makes requests, gets responses back from app A.

How can app A create a destination to app B from info provided to app A's request handler, so that app A can establish a link in reverse to app B at a later point in time?

I tried the following but RNS.Identity.recall returns None.

        remBinHash = bytes.fromhex(remote_id)  # <-- saved by request handler
        remID = RNS.Identity.recall(renBinHash)   # <-- returns None
        remDest = RNS.Destination(remID, RNS.Destination.OUT, 
                                  RNS.Destination.SINGLE,
                                  self.AppName)

However, within the request handler this will create the outgoing destination:

        remID = RNS.Identity.recall(remote_identity.hash)
        remDest = RNS.Destination(remID, RNS.Destination.OUT, 
                                  RNS.Destination.SINGLE,
                                  self.AppName)

Given that, I just need a way to save the remote_identity in a file for use later to create a destination. What is the best way to do that? I have tried to save the remote_identity to a file, but I get "'str' object has no attribute 'hexhash'" or other value type errors on the variations I've tried.

[faragher]

I need to write a routine for my own app, but it's very late and that's a problem for Tomorrow Me. Here's some basic information if you get back to work before I finish an example.

Reticulum doesn't provide sender information as part of the packet. Without an active measure from the sender, there's no way to determine their identity. Since you're creating a link, you can use that to identify the sender.

From the Identify example:

[link].identify([your client identity])

should send your identity to the server. I don't know if it saves it as a known destination automatically. In a pinch you can use identity.from_file/to_file to save a specific identity.

The "'str' object has no attribute 'hexhash'" error is a type issue. What ever you're feeding it into isn't expecting a string, it's probably expecting an identity. It's not entirely clear, since simply calling the identity returns a string, but it's a full class with a number of pieces of information, such as cryptographic keys.

Also, an identity's hash isn't always the hash you're looking for, since the identity hash could be AAA, but LXMF.message would be BBB, and AppName,aspect would be CCC. It's predictable if you know AAA and the full name, but otherwise there are a limitless number of potential destination addresses linked to a specific identity.

[faragher]

Ah. I found my error, and it's the same as yours. RNS.Identity.recall accepts a byte array, not a string.

Try this:

[RequiredIdentity] = RNS.Identity.recall(bytes.fromhex([StoredHash]))

[ThomasFreedman]

I don't think that is my issue. I've gone thru several iterations of code on this, and am getting back to it after some unrelated network issues.

In your case the identity has already been persisted and you had an issue on restoration. In my case I haven't been able to get it saved. It seems we are both attempting to do the same or very similar things. Where are you obtaining your identity value? The examples to create an identity, save it to disk then read it back and use it to create destinations work without issue for me, I use them in my app startup. It looks to me like there are variations of "identity" values in RNS.

Since I was able to successfully create a destination within the context of the message handler:

# remote_identity is an argument to message callback supplied by RNS API.
# These 2 lines succeed within the message handler
appBid = RNS.Identity.recall(remote_identity.hash)  # <-- from API, not disk
destB = RNS.Destination(appBid, RNS.Destination.OUT, RNS.Destination.SINGLE,
                        self.AppName)

# This fails if it is uncommented:
# appBid.to_file("appBid")

It appears the return value from RNS.Identity.recall can't be persisted directly, even tho it is an acceptable identity value to create a destination. The value returned from RNS.Identity() is not the same type as RNS.Identity.recall(...) returns.

The question is, can the identity from RNS.Identity.recall be manipulated in some way that it can be persisted? If not why not? How can I create a destination to the initiator of the link my message handler is replying to for later use?

[faragher]

Neat! So the identity is functional. In Reticulum's Identity.py there's validate_announce which gives an example of how to call RNS.Identity.remember

remember(packet_hash, destination_hash, public_key, app_data = None):

I'm not sure the need of packet_hash, it doesn't seem to get loaded in recall, but that should get the identity into known_destinations. Just remember to save it as well.

RNS.Identity.save_known_destinations()

[ThomasFreedman]

Ok, got more info. First, I may have used "request_id" rather than "remote_identity" in some of my tests. My OP stated "remote_id" which may have been literal or an abreviation of the correct value.

Although I said I was able to create a destination to app B, it was always based on appBid == None. Seems it's possible to create a destination with None as the first arg.

Once I discovered that I evaluated what the API was providing for remote_identity. I added:
print(type(remote_identity), remote_identity, remote_identity.hash) to the handler which printed:
<class 'RNS.Identity.Identity'> <11........cc> b'\x11........\xcc' The type of remote_identity is identical to what RNS.Identity() returns, so saving it to disk with the "to_disk" method should work, but fails with:
The contained exception was: unsupported operand type(s) for +: 'NoneType' and 'NoneType' when I used this code: remote_identity.to_file("/tmp/appBid.rns") - that looks like an RNS bug to me, since I proved the type & value of remote_identity is valid and the arg to the "to_file" method is valid.

[faragher]

The reason

print(type(remote_identity), remote_identity, remote_identity.hash)

looks the way is does is when you call remote_identity in that it returns a string populated with the pretty hash. This is because of this function:

    def __str__(self):
        return RNS.prettyhexrep(self.hash)

Calling remote_identity.hash actually returns the variable from the class.

Since you can't concatenate None data types, that error is predictable, but it shows something interesting. You have two None values in your Identity that can't be None. Walking through the to_file function, it appears the only place this could be is in get_private_key:

return self.prv_bytes+self.sig_prv_bytes

Unfortunately this shows a misunderstanding on my part: to/from_file only works for identities with a private key. None+None is because you don't have private keys for a remote destination.

You could write new routines that make an identity for public key based identities or add them to the known_hosts. Sorry for not drilling down on to_file.

[ThomasFreedman]

I see the save & load_known_destinations in Identity.py soure file, but without a way to reference them I'm not so sure it helps to resolve the problem I expressed in the OP.

The NoneType+NoneType error I see when trying to save the remote_identity must be coming from Identity.get_private_key method, which returns self.pub_bytes+self.sig_pub_bytes. That's the only + operator involved.

That actually makes sense, that the private key from a remote_identity doesn't exist. Although that doesn't seem like a bug, it should be documented and explicit.

The problem expressed in the OP remains however, how do I create a destination to the initiator of a link?

[ThomasFreedman]

I decided to temporarily hard code a destination so I could finish coding a function and figure out how to derive the destination from the traffic across the established link later. App B prints a destination hash at startup using RNS.prettyhexrep which I added to app A (full hash like "<ac123...ef890>").

I use that destination string inside app A's message callback (that handles app B's requests), the same way as the Requests & Responses example:

appBdest = bytes.fromhex("<ac123...ef890>"[1:-1])
print(f"{appBdest.hash} has path: {RNS.Transport.has_path(appBdest)}")

which prints the hexified bytes of app B's destination string and False. If a link exists and thus a path between B and A wouldn't that path also be valid for A to B? Paths can't be based on identity or destinations which can move, thus changing the path. The only reason a path wouldn't exist is if the no traffic traveled through the nodes between destinations. If the intermediate nodes don't change why should the path?

Even within a link's request message callback where communication is occurring and thus a path must exist, RNS.Transport.has_path(appBdest) returns false.

I can't seem to even create a reverse link manually. It shouldn't be this difficult, I must be doing something wrong here.

[ThomasFreedman]

Thinking further about this, even if the reverse path was valid, it probably shouldn't be relied upon to exist at a later point in time.

I'm thinking about a scenario where app A disconnects from app B after conveying work to do, then reconnects later to get the status of that work. If app A is mobile, or even if stationary the RNS path between them could change between time of disconnect and reconnect for status request. RNS is designed to be dynamic and routes to destinations can change for the same destinations (destination != location).

So although it will be more work to implement a path request involving the UI event loop, timer & delays impacting UX, it is a better and more robust design to do so.