Closed joshuafhiggins closed 8 months ago
Oh this is hilarious. I don't know how the others will react to this but I think it'd have a better chance of getting merged if it was setup as an optional feature.
Oh this is hilarious. I don't know how the others will react to this but I think it'd have a better chance of getting merged if it was setup as an optional feature.
I was wondering if there was a way to add it to the API but not require the other bridge types to implement them, I'll look into it.
@joshuafhiggins I haven't tested this but the code looks fairly straightforward and clean. I am not concerned about the "false" reporting of the bridge type, because it was already doing that to enable the tapback features. I'll try to test it early this upcoming week and get it merged for a real pre-release review (along with the other features I have ready to merge).
I'll be darned, it actually works. Unfortunately I ran a delete before I started the bridge with your changes, so I don't know whether it requires a delete to make the features available in beeper.
Implements #190 and #191
This works by telling Beeper that it is the
imessagego
bridge that had implemented edits and unsends before. This is not ideal to use an unsupported bridge's ID and we should probably ask if Beeper could give BlueBubbles its own Protocol.ID. This is my first time working in golang so let me know if any changes are needed. I've only ran some initial tests and the features seem to work with this, but again let me know.