Wednesday February 10 2021 22:01, you wrote to me:
MvdV> For a human reader: sure. But you got me wrong. What I proposed was MvdV> letting the gateway do the translation the other way for the other MvdV> direction. For the (netmail) message FROM Fidonet TO Telegram. Translate MvdV> Fidonet "John Carpenter" to "31254657345". The Fidonet user will only MvdV> have to deal with "John Carpenter.
MvdV> But if for some reason that is not doable...
If I understood you correctly this time, then it really is not possible. The Telegram user has a unique user_id. There is a required field first_name, second_name and username - fields are optional. Besides, as you already guessed, all these fields are not unique. Moreover, they are not permanent. The user can change them at any time at will.
SM>> It is much more pleasant to receive a message from John Carpenter, SM>> but not from 31254657345 and at the same time be able to answer SM>> automatically.
MvdV> For a human, sure. But a robot does not care. A PING robot will just as MvdV> happily process and answer a message originating from user "31254657345" MvdV> as a message originating from "John Carpenter".
But this is quite possible to implement. Most likely I will. Thanks for the tip.
MvdV> If you configure your gate to translate "Jon Carpenter" into MvdV> "31254657345" for message to user Ping and only for messages to user MvdV> Ping, then it will work as you desire without the PING robot having to MvdV> recongnise @REPLYTO.
Some users sometimes write to ping to make sure that everything works for me and the delay in responding to the message was not my fault.
SM>> I think this is not a necessary toy. It is quite enough that my ping SM>> will recognize the name substitution when responding.
MvdV> But then it will only work for Pings processed by YOUR ping robot. Ping MvdV> messages coming from Telegram will not usually be addressed to your PING MvdV> robot. PING is designed for testing the routing in Fidonet. Sendig a MvdV> ping message from Telegram to your PING robot which is the gateway does MvdV> not make much sense, there is no Fidonet routing to test that way. What MvdV> does make sense in your scenario is to send a PING message to a Fidonet MvdV> node that is not your Telegram gateway. And that will work as desired if MvdV> you configure your gateway as I propose.
I agree. This can be helpful too. I think this is how I implement it. Thanks again for the tip.