This can become a problem when the same messages from Fido will appear in the same Telegram group, gated on different nodes with different msgid.

Yes.. I can see a problem if different bots pull and feed with the same original Telegram group. Maybe there should be some kind of other-bot-aware mechanism that can be added as a kludge. Do Telegram messages have something like a msgid?


--- tg2fido.pl
* Origin: Telegram to fido gate by Stas Mishchenkov (2:460/58)

Hello, August Abolins.
On 9/12/20 5:52 PM you wrote:

Yes.. I can see a problem if different bots pull and feed with
the same original Telegram group. Maybe there should be some kind
of other-bot-aware mechanism that can be added as a kludge. Do
Telegram messages have something like a msgid?

For example, if some replies to this message, it would only flag as to me when I read it from this address. If I were on my other point, the message would be there, but Charles Pierson at the Z2 address isn't the same person as Charles Pierson at the Z4 address. And neither are the same person as Charles Pierson on Telegram, who I think also may be another Z2 address based on the bot's address in Fido?

--
Best regards!
Posted using Hotdoged on Android
--- Hotdoged/2.13.5/Android
* Origin: The Oasis, Houston, Texas, USA (2:240/1120.976)

Hi, August!

12 ᥭ 20 17:52, August Abolins -> Brother Rabbit:

Yes.. I can see a problem if different bots pull and feed with the
same original Telegram group. Maybe there should be some kind of other-bot-aware mechanism that can be added as a kludge. Do Telegram messages have something like a msgid?

If you remember, bots do not see messages from each other and this should not be a problem, but the possibility of flooding in the Telegram channel remains.

Have nice nights.
Stas Mishchenkov.

--- Œ­¥ ¡¥á¯®«¥§­® çâ®-«¨¡® § ¯à¥é âì, ï ¨ â ª ­¥ ᮡ¨à îáì ­¨ç¥£® ¤¥« âì.
* Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)

Hello Charles!

** On Saturday 12.09.20 - 10:09, Charles Pierson wrote to August Abolins:

For example, if some replies to this message, it would
only flag as to me when I read it from this address. If
I were on my other point, the message would be there, but
Charles Pierson at the Z2 address isn't the same person
as Charles Pierson at the Z4 address. And neither are the
same person as Charles Pierson on Telegram, who I think
also may be another Z2 address based on the bot's address
in Fido?

I don't see a problem if there would be only one bot assigned
to a group, just as it is now.

If another bbs wants to gate that echo's traffic to Telegram,
they would have their own bot and their own group (with
similar name) to manage.

A post at StasFUTURE4FIDO-group, then to StasTelebot, then to
StasBBS, then to Fidonet, then to CharlesBBS, then to
CharlesTelebot, and then to CharlesFUTURE4FIDO-group wouldn't
be a problem.

CharlesFUTUR4FIDO-group and StasFUTURE4FIDO-group are separate
groups. It is no different than each BBS having its own copy
of a distributed echo.

Is there a scenario that I am missing?

--
../|ug

--- OpenXP 5.0.46
* Origin: The future is not what it used to be. (2:221/1.58)

Hello, August Abolins.
On 9/12/20 7:30 PM you wrote:

I don't see a problem if there would be only one bot assigned to
a group, just as it is now.

This case isn't a problem, no. Except perhaps in the case of either the bot or the system attached to it going offline. Then it's just a matter of the backlog of messages from both sides coming through when the down section comes back online.

If another bbs wants to gate that echo's traffic to Telegram,
they would have their own bot and their own group (with similar
name) to manage.

That's not a scenario I thought too much about.

A post at StasFUTURE4FIDO-group, then to StasTelebot, then to
StasBBS, then to Fidonet, then to CharlesBBS, then to
CharlesTelebot, and then to CharlesFUTURE4FIDO-group wouldn't be
a problem. CharlesFUTUR4FIDO-group and StasFUTURE4FIDO-group are
separate groups. It is no different than each BBS having its
own copy of a distributed echo. Is there a scenario that I am
missing?

I didn't consider separate groups for separate bots, as it looks somewhat overcomplicated.
I was only considering a second bot as a backup in the cases where the original bot or system dropped out for a time.

I go through ideas in my head much faster than I can explain them. And often things get missed when I explain.

--
Best regards!
Posted using Hotdoged on Android
--- Hotdoged/2.13.5/Android
* Origin: The Oasis, Houston, Texas, USA (2:240/1120.976)

Hello Charles!

** On Saturday 12.09.20 - 18:46, Charles Pierson wrote to August Abolins:

..Except perhaps in the case of either the bot or the
system attached to it going offline. Then it's just a
matter of the backlog of messages from both sides coming
through when the down section comes back online.

That could be a doozy. I think we experienced something akin
to that when Stas turned on the bot after a brief interlude.

If another bbs wants to gate that echo's traffic to
Telegram, they would have their own bot and their own
group (with similar name) to manage.

That's not a scenario I thought too much about.

Maybe until all the unique identifier stuff (^TG_PID, or
^TG_MSGID) can be sorted out, then just have it so that there
is only one gate-bot per group, and each BBS is responsible
for their own group.

If there are multiple bots per one group, then the MEMBERS
column could get pretty full. BUT, it would look cool if the
MEMBERS list denotes ALL members to the echo/group and not
just the ones that are getting gated through Stas's bot.

As it sits right now, we appear to be members of Stas' BBS
only.

I didn't consider separate groups for separate bots, as
it looks somewhat overcomplicated. I was only considering
a second bot as a backup in the cases where the original
bot or system dropped out for a time.

The gating is probably far from being a shared process with
multiple bots at this time. But Stas is in a fine position to
be the founder of establishing the standard ground-rules and
the checks and balances for managing dupes, avoiding loops,
coming up with the new terminologies for this thing, etc.

I go through ideas in my head much faster than I can
explain them. And often things get missed when I explain.

:)

--
../|ug

--- OpenXP 5.0.46
* Origin: The future is not what it used to be. (2:221/1.58)

Hi, Charles!

12 ᥭ 20 18:46, Charles Pierson -> August Abolins:

This case isn't a problem, no. Except perhaps in the case of either
the bot or the system attached to it going offline. Then it's just a matter of the backlog of messages from both sides coming through when
the down section comes back online.

Of course, I would like to have the reliability of work comparable to Telegram services, but we must not forget that Fido is an amateur network and most of the nodes are located on home computers, the reliability of which is not comparable to the reliability of data centers. The same goes for software.
Of course, we must strive for high reliability and uninterrupted operation, but it is not always possible to provide this with amateur means.

Have nice nights.
Stas Mishchenkov.

--- ‘­¥á«  ªãà®çª  ï¨çª® áâ à¨ªã ¨ ¢ëà §¨â¥«ì­® ¯®á¬®â५  ­  ¬®¤¥à â®à .
* Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)

Hi, August!

12 ᥭ 20 20:44, August Abolins -> Charles Pierson:

Maybe until all the unique identifier stuff (^TG_PID, or
^TG_MSGID) can be sorted out, then just have it so that there
is only one gate-bot per group, and each BBS is responsible
for their own group.

A standard PID is enough to eliminate flooding and duplication.

As it sits right now, we appear to be members of Stas' BBS
only.

From Fido's point of view, this is exactly the case. However, I must remind you that there were not so many Internet gates, even during the heyday of the network, in contrast to the BBS.

I didn't consider separate groups for separate bots, as
it looks somewhat overcomplicated. I was only considering
a second bot as a backup in the cases where the original
bot or system dropped out for a time.

The gating is probably far from being a shared process with
multiple bots at this time.

By the way, I have a strong desire to bring the code to the state of free software, but to make it such that it would be impossible to use it without sufficient knowledge.

But Stas is in a fine position to be the founder of establishing the standard ground-rules and the checks and balances for managing dupes, avoiding loops, coming up with the new terminologies for this thing,
etc.

From Fido's point of view, this is just another kind of BBS.

Have nice nights.
Stas Mishchenkov.

--- ‘ ¬®¥ áâà è­®¥ ­¥ â®, çâ® ¬ë ⥯¥àì ¢§à®á«ë¥. € â®, çâ® ¢§à®á«ë¥ ⥯¥àì ¬ë
* Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)

Hello, Stas Mishchenkov.
On 9/13/20 11:19 AM you wrote:

Of course, I would like to have the reliability of work comparable
to Telegram services, but we must not forget that Fido is an
amateur network and most of the nodes are located on home
computers, the reliability of which is not comparable to the
reliability of data centers. The same goes for software. Of
course, we must strive for high reliability and uninterrupted
operation, but it is not always possible to provide this with
amateur means.

When comparing Fidonet now to to say the mid 1980's, the reliability is amazing. As well as the speed.
We now can exchange several messages in the same conversation daily. In 1985, it could take a week or longer for a single reply from you to reach me, if indeed it ever did.
Well, I should say in many places.
While it is not a totally fair comparison in my case. This point is in Z2, the same as you are. I also have a point in Z4, which is slower on the transfer of messages, but still much faster than it was in 1985.
So while yes, it is an amateur network, these amateur people that work on it are no less dedicated to improving it than any data center. It just might take longer due to the amount of time the amateur can spend working on their projects.
Just the fact that I see discussions throughout Fido where people are setting up virtual machines on their modern computers to run sometimes antiquated software to participate in Fido yells me there is all sorts of creativity to be tapped into.

--
Best regards!
Posted using Hotdoged on Android
--- Hotdoged/2.13.5/Android
* Origin: The Oasis, Houston, Texas, USA (2:240/1120.976)

Hello Stas!

** On Sunday 13.09.20 - 11:19, Stas Mishchenkov wrote to Charles Pierson:

Of course, I would like to have the reliability of work
comparable to Telegram services, but we must not forget
that Fido is an amateur network and most of the nodes are
located on home computers, the reliability of which is
not comparable to the reliability of data centers.

At least the conversations for TgM users will be unaffected
with a downtime in FTN.

The situation is not unlike a group of users feeding off one
particular BBS while all the other BBSes in the network are
offline. At least the users associate with the 1st BBS can
keep communicating. In the TgM case, the users will have the
reliability of a well supported data center.


--
../|ug

--- OpenXP 5.0.46
* Origin: The future is not what it used to be. (2:221/1.58)

Hello, August Abolins.
On 9/14/20 8:53 PM you wrote:

Hello Stas! ** On Sunday 13.09.20 - 11:19, Stas Mishchenkov wrote
to Charles Pierson:

Of course, I would like to have the reliability of work
comparable to Telegram services, but we must not forget that Fido
is an amateur network and most of the nodes are located on home
computers, the reliability of which is not comparable to the
reliability of data centers.

Strange. I don't recall seeing this message. And age is making the memory bad.

At least the conversations for TgM users will be unaffected with
a downtime in FTN.

Ahh, the joys of conversations going on. Then everyone playing catch-up when the break down is fixed.

The situation is not unlike a group of users feeding off one
particular BBS while all the other BBSes in the network are
offline. At least the users associate with the 1st BBS can keep communicating. In the TgM case, the users will have the
reliability of a well supported data center.

There is that.

--
Best regards!
Posted using Hotdoged on Android
--- Hotdoged/2.13.5/Android
* Origin: The Oasis, Houston, Texas, USA (2:240/1120.976)

Hello Charles!

** On Monday 14.09.20 - 20:23, Charles Pierson wrote to August Abolins:

Of course, I would like to have the reliability of work
comparable to Telegram services, but we must not forget
that Fido is an amateur network and most of the nodes
are located on home computers, the reliability of which
is not comparable to the reliability of data centers.

Strange. I don't recall seeing this message. And age is
making the memory bad.

:) Try TgM's S)earch feature. It's awesome. Keyword "centers"
is a good one to find the original message.

--
../|ug

--- OpenXP 5.0.46
* Origin: The future is not what it used to be. (2:221/1.58)

Answering a msg from August Abolins:

Hello Charles!

** On Monday 14.09.20 - 20:23, Charles Pierson wrote to August Abolins:

Of course, I would like to have the reliability of work
comparable to Telegram services, but we must not forget
that Fido is an amateur network and most of the nodes
are located on home computers, the reliability of which
is not comparable to the reliability of data centers.

Strange. I don't recall seeing this message. And age is
making the memory bad.

:) Try TgM's S)earch feature. It's awesome. Keyword "centers"
is a good one to find the original message.

--
../|ug

I remember it now.


--- tg2fido.pl
* Origin: Telegram to fido gate by Stas Mishchenkov (2:460/58)