In order to implement #64, the bot needs to be able to record the ids of messages it sends, tagged with some kind of metadata related to its content/purpose.
Right now, most messages the bot sends are done so implicitly (by having module dispatchers fill data into a MessageBuilder and allowing the MultiBot dispatcher send it out through ntelebot). This means that, for example, the events module can't just capture the return value from MessageBuilder.reply and store the id somewhere internally.
One possibility would be to have MultiBot record all messages it sends, and make them available via ctx. events could then look backward through the record to find something in the given chat that looked like something it sent and perform #64's update logic on it. This could go a step further and have MultiBot actually keep track of which module ended up capturing the update and tag it by name in the record (and/or keep messages separated by module), so events would just have to look for its most-recent message in the given chat.
A slight variation would be to have modules explicitly mark messages (via MessageBuilder) that they want a record of, maybe setting msg.record = __name__ or msg.tags.add(__name__). Only so-tagged messages would then be recorded by MultiBot (or directly by MessageBuilder).
In order to implement #64, the bot needs to be able to record the
ids of messages it sends, tagged with some kind of metadata related to its content/purpose.Right now, most messages the bot sends are done so implicitly (by having module dispatchers fill data into a MessageBuilder and allowing the MultiBot dispatcher send it out through ntelebot). This means that, for example, the
eventsmodule can't just capture the return value fromMessageBuilder.replyand store theidsomewhere internally.One possibility would be to have MultiBot record all messages it sends, and make them available via
ctx.eventscould then look backward through the record to find something in the given chat that looked like something it sent and perform #64's update logic on it. This could go a step further and have MultiBot actually keep track of which module ended up capturing the update and tag it by name in the record (and/or keep messages separated by module), soeventswould just have to look for its most-recent message in the given chat.A slight variation would be to have modules explicitly mark messages (via MessageBuilder) that they want a record of, maybe setting
msg.record = __name__ormsg.tags.add(__name__). Only so-tagged messages would then be recorded by MultiBot (or directly by MessageBuilder).