Open dequis opened 3 years ago
1ay1
commented
3 years ago HI @dequis I think I can take this forward, I don't have worked on libpurple before per se but I have fair knowledge of Glib and GTK+ and of course C, I think getting to know libpurple API won't be an issue for me. I have been using this plugin from years now and would love to be of any help.
dequis
commented
3 years ago @0bhat hmm, maybe start by throwing some PRs or reviewing some stuff?
1ay1
commented
3 years ago Alright, I'm gonna start with trying to fix the build system and get rid of this patches mess. Please suggest if you want it in a particular way.
1ay1
commented
3 years ago Is retaining author meta data important? Without that it will be much easier to shift this to some other build system, I'm planning to migrate it to cmake.
mvandemar
commented
3 years ago HI @dequis I think I can take this forward, I don't have worked on libpurple before per se but I have fair knowledge of Glib and GTK+ and of course C, I think getting to know libpurple API won't be an issue for me. I have been using this plugin from years now and would love to be of any help.
@0bhat Is your fork now the official one, or are you still working on it? If it's in release mode, should the main package readme be updated to indicate that?
1ay1
commented
3 years ago No it's not yet. I'm still working on this, this is still the official repo.
jaymzh
commented
2 years ago @0xfe0 Just wanted to follow up and see how you're doing
grimmy
commented
2 years ago Is retaining author meta data important? Without that it will be much easier to shift this to some other build system, I'm planning to migrate it to cmake.
Not sure whatever happened here, but the intent is for upstream (the pidgin repo) to split this out to a separate mercurial repository for pidgin3 and build it as a meson subproject. I have no timeline on that right now, but that is the eventual plan.
jonasstein
commented
2 years ago I hope you will find a new maintainer soon. We advertised this call too, because otherwise we will have to drop the package from Gentoo https://bugs.gentoo.org/830331.
fangfufu
commented
2 years ago @EionRobb, I wonder if you are interested in this.
antdude
commented
2 years ago Still nothing?
usvi
commented
2 years ago Does there need to be the same maintainer for both purple-facebook and bitlbee-facebook? Or is it just a wish for synergy convenience?
jaymzh
commented
2 years ago @usvi - @dequis can give a more complete answer, but in the meantime...
My understanding is that no, they don't have to be the same, however, currently the codebases and build systems are separate (this code checks out that code and then patches it, etc.) which makes maintainership of either/both very difficult and one of the hopes was to combine them into a single code base, so someone willing to do that would probably get the project moving faster and make it easier for outside contributions. That said, dequis has no time at the moment, any maintainership is probably welcome, even if it's just to move one or the other side along.
jaymzh
commented
2 years ago @1ay1 - just curious if you're still interested in taking on a maintainership role. I have some mediocre C skills and might be able to contribute, but at the moment the weird state of the dual repos mean I find it nearly impossible to find the code I'm looking for. Since you were looking at fixing that, I wanted to follow up.
bish0polis
commented
2 years ago When you DO pass this project over, consider making it under a new, independent account.
usvi
commented
1 year ago I'm starting to think we need to find an alternate solution to this situation.
dequis
commented
1 year ago You mean the situation of no one wanting to work for free?
greatquux
commented
1 year ago Yeah I don't want to complain if someone does not have the time to look into these things. And I'm sure Facebook does not make it easy to do so either. I did switch to using WhatsApp (which basically everyone I used FB for can also use) since it has a maintained libpurple plugin. Using pidgin is still important to me since I use other GNOME extensions that let me reply from notifications and it really helps a lot not having to go back and forth to pidgin windows to chat. Can't believe KDE or other desktops don't have that kind of quick reply. Thanks for all your work on this over the years!
jaymzh
commented
1 year ago @dequis Just for my own clarity - is it a money issue primarily, or a time/interest issue? I've certainly paid/donated for a few features in the past and would be willing to do so again. My understanding is you simply don't have the time (and interest) anymore (which I totally get).
@greatquux & @usvi - it's quite complicated. Forgetting the hard engineering work of reverse-engineering various protocols and features and re-implementing them, there's a fair amount of just housekeeping and tech debt in this project that needs doing which isn't fun work. The build process for this is complicated and requires a pretty deep understanding of both the bitlbee-purple project and this one, which itself requires knowing multiple programming languages and build tools not to mention the fairly complex codebases themselves. Dequis did a write-up of the steps required to simplify all of that and make it nicer, but it's a lot of not-fun work. Addressing that would make it easier for various one-off or small contributors, which might then lead to someone willing to take a more active role... MAYBE. All of which ignores the really hard work of tracking down all of FBs changes to a completely undocumented and purposefully obfuscated protocol that changes nearly daily. And remember that all of this is open source a, unpaid, volunteer time.
usvi
commented
1 year ago I'm not claiming anything on anything. I'm not blaming anyone for anything. I'm not entitled to anything. I'm just sad. Mind if I tell why? I worked so hard on the 2FA code thing, got it working and wanted to share it for everyone. Now I'm probably the only person on planet having properly working bitlbee-facebook with 2FA. Just.. understand my interest, ok?
Lots of shitty infrastructure unfucking honestly sounds like me. Been doing it with C, C++ and Python recently 300 hours a month. I'll see when I'm down to more humane levels. I might step forward and volunteer. If that happens, I would appreciate someone to team-up and question my actions as I go.
mjeveritt
commented
1 year ago I'll put my hand up here, and say that, whilst I was an avid pidgin user for a while, I had to succumb to the Electron apps, and latterly Ferdi for my 'modern' IM needs; however, I am prepared to step up and do some testing and perhaps code review, but I'm by no means proficient in C/C++ or modern frameworks, so am less useful in the code design/implementation phases of this project. So, if that helps get us off the blocks, let me know!
jaymzh
commented
1 year ago @usvi - I think that'd make a huge impact. @dequis has offered to review PRs and provide direction in a few other places.
fangfufu
commented
1 year ago @usvi , you can always fork the project. I wouldn't mind using your fork for now.
usvi
commented
1 year ago @usvi , you can always fork the project. I wouldn't mind using your fork for now.
Heh, thanks for the confidence. I have a fork and branch for testing my code changes ( https://github.com/usvi/bitlbee-facebook/tree/automatic-2fa-tokens ). But I'd rather like "civilized" solution. And I have only the bitlbee part. I gathered that best course of action is to unify things? Maybe even under single repo? I need to read about how this was planned. In my opinion forking many times creates confusion and makes things harder and divides people into warring tribes :(
There is also great value in issue texts in both the existing repos. I would not want to lose those unless absolutely needed.
It's a good thing we got indication that the maintainer is still somewhat following. Lets see. I'm positive there will be a resolution later this year.
dequis
commented
1 year ago @usvi threw invites your way, does that help?
I gathered that best course of action is to unify things? Maybe even under single repo?
Maybe? Optional.
@dequis has offered to review PRs and provide direction in a few other places.
I probably said that in the past but now I'm not really up to any serious C code review.
grimmy
commented
1 year ago I'll throw this out there before people get too invested in a new fork and then get mad at me later..
Pidgin 3 and Purple 3 are nearing an alpha. No i don't have a date, but I do have a [milestone in our issue tracker](https://issues.imfreedom.org/issues?u=1&q=(Scheduled%20versions:%203.0.0-alpha1%20)%20and%20(%23unresolved) which will ebb and flow until we get to a release.
The goal of the alpha is to have rough Pidgin 2 / Purple 2 functionality (mostly around messaging) but with the ability to add modern messaging stuff in the near future. We're also aiming to get the protocol API layer as close to final as possible because, as you may have guessed, most protocol plugins will more or less have to be rewritten. At least the parts that talk to libpurple. We're doing a lot here to try to simplify that work as much as possible, but it's going to require a lot of work from everyone to port to purple3 regardless.
Also fwiw, there has been some discussion between myself and another contributor about possibly writing a new Facebook protocol plugin that uses the web API instead of using MQTT like this one does. That said, it's only been discussed and I'm not aware of any actual code being written for it as my priorities are the alpha and the other contributors priorities are elsewhere as well.
Hope this helps :)
jaymzh
commented
1 year ago @usvi - there's no reason to fork, PRs here will do just fine. And now that @dequis has sent you invites, you can simply make a branch here for your work and merge it once you are happy with it.
@grimmy - Thanks for that, I had forgotten about Purple 3. That does change things a bit. I love the idea of using the web API, especially if there's some folks interested in writing/maintaining it.
LurkerHub
commented
1 year ago most protocol plugins will more or less have to be rewritten. At least the parts that talk to libpurple. We're doing a lot here to try to simplify that work as much as possible, but it's going to require a lot of work from everyone to port to purple3 regardless.
This may not be the the best place to discuss it, but it has to be mentioned.
To most people, Pidgin is only as good as its protocol support, and the protocols that people use in non-corporate settings are almost exclusively implemented by by plugins. Unfortunately, it seems that the amount of effort that plugin writers are willing to invest in actively maintaining their plugins has been waning, and the "require a lot of work" part will limit Pidgin3 adoption.
usvi
commented
1 year ago @usvi threw invites your way, does that help?
Most certainly once I get fully rolling. Thank you for your trust.
@dequis has offered to review PRs and provide direction in a few other places.
I probably said that in the past but now I'm not really up to any serious C code review.
Ok, lets see if I/we can create a low-effort setting for wrapping up things.
Everyone else: Thank you also for your contributions and comments. I have a ton of stuff to read and comprehend.
Hawk777
commented
1 year ago Unfortunately I have to agree with @LurkerHub . For me, personally, I don’t need fancy new features or a different UI or whatever new-and-shiny is going into Pidgin 3. Sure I might find some of it useful, but if I could have three wishes for Pidgin, it would be:
So, basic functional stuff. And yes, I’m perfectly aware that those three are all third-party plugins, not shipped by Pidgin themselves, but as an end user, that doesn’t matter—I use the protocols I need to to talk to the people I want to, because that’s where those people are, first-party or third.
grimmy
commented
1 year ago Unfortunately I have to agree with @LurkerHub . For me, personally, I don’t need fancy new features or a different UI or whatever new-and-shiny is going into Pidgin 3. Sure I might find some of it useful, but if I could have three wishes for Pidgin, it would be:
Fixed in purple3 by using the system certificate store instead of our own busted stuff.
Can't be implemented in purple2 in any reasonable way without serious breaking the API and therefore creating purple3 anways. That said, about halfway done in purple3/pidgin.
Related to the previous one, purple3 has a history api that can keep track of all of this whether a window is displayed or not and allows back loading of history as well.
So, basic functional stuff. And yes, I’m perfectly aware that those three are all third-party plugins, not shipped by Pidgin themselves, but as an end user, that doesn’t matter—I use the protocols I need to to talk to the people I want to, because that’s where those people are, first-party or third.
Understandable, but there's a lot more to pidgin3 than just the "whatever new-and-shiny" and the finding/updating protocols thing is something I tackled in this week's blog post that will go public on Thursday at 0500 UTC but is available for patrons now.
grimmy
commented
1 year ago To most people, Pidgin is only as good as its protocol support, and the protocols that people use in non-corporate settings are almost exclusively implemented by by plugins. Unfortunately, it seems that the amount of effort that plugin writers are willing to invest in actively maintaining their plugins has been waning, and the "require a lot of work" part will limit Pidgin3 adoption.
I'm well aware of this and making things easier for all developers but especially protocol developers is one of the primary focuses when designing our new apis. Rewriting all of the parts that touch libpurple is a big ask, and they only way it's going to happen is if there's good reasons like better feature support and apis that offload a lot of work from the protocol developers.
I know it's easy to armchair debate this, but please follow the development blog on my patron (all post go public within a few days), check out my twitch streams where we developer pidgin3 and address these issues live, or the best option, participate in our new discourse so that others may see these discussions rather than having to find them in an issue tracker for a related project.
Hawk777
commented
1 year ago Good to hear! I admit, a week ago I didn’t know that Pidgin 3 was even a thing that existed. It wasn’t at all obvious that things that looked like bugs in specific protocol plugins (and as for fetching messages sent while I was offline, plenty of other protocols do it) and were reported as such (on individual plugins’ ticket trackers) are actually going to be helped by core changes, but that’s definitely good news.
grimmy
commented
1 year ago Good to hear! I admit, a week ago I didn’t know that Pidgin 3 was even a thing that existed. It wasn’t at all obvious that things that looked like bugs in specific protocol plugins (and as for fetching messages sent while I was offline, plenty of other protocols do it) and were reported as such (on individual plugins’ ticket trackers) are actually going to be helped by core changes, but that’s definitely good news.
Pidgin 2 (and therefore purple2) were created in a time before historical messages where a thing and the API never grew support for it. But worse than that, the APIs weren't designed in a way to accommodate adding those features at all, which is why all of this has to go to Pidgin 3/Purple 3. I know it's a bummer that it's taking so long, but we only have 3 unpaid contributors and there's a TON of work to do.
If you want more updates on what's going on, I do a quarterly update call The State of the Bird that usually runs about 45 minutes describing what we've done that past quarter. You can find a youtube playlist here. We do also occasionally blog about stuff on the main site but that's not going to have development stuff.
antdude
commented
1 year ago So basically, v3 is a major revamp to Pidgin from scratch. If so, then this is a good thing!
On Tue, Feb 28, 2023 at 02:51:35PM -0800, Gary Kramlich wrote:
Pidgin 2 (and therefore purple2) were created in a time before historical messages where a thing and the API never grew support for it. But worse than that, the APIs weren't designed in a way to accommodate adding those features at all, which is why all of this has to go to Pidgin 3/Purple 3. I know it's a bummer that it's taking so long, but we only have 3 unpaid contributors and there's a TON of work to do. ...
grimmy
commented
1 year ago It's not from scratch, it's in place, but there's had pros and cons. Either way, check out the state of the birds for more indepth stuff.
LurkerHub
commented
1 year ago Is there any cooperation or cross-pollination with other multiplatform clients like Miranda NG? (In the spirit of the Trillian/Gaim cooperation against Yahoo's blocking attempts)
grimmy
commented
1 year ago Only when it comes to figuring out protocol stuff, that's why there's stuff like this repo and https://github.com/bitlbee/bitlbee-facebook. When it comes to the projects themselves, not really as they're all written in different languages.
DMJC
commented
1 month ago I've implemented meson and I've implemented working 2FA, not looking to take on maintainer, but I'd love it if my PRs were pulled into the upstream repo. For anyone who wants to try my code out just jump on my github repo: https://github.com/DMJC/purple-facebook The main thing outstanding atm is the end to end encryption. I'd need more information about how that works to do any sort of implementation.
jaymzh
commented
1 month ago @DMJC - I tried it... but I don't see how 2FA is supposed to work. It fails the same way the old one fails. It just says Login approvals are on. Expect a code to use for log in (406) and I can choose "Modify Account" or "Reconnect".
(I'm assuming when you say you implemented 2FA, you don't mean I still need to use my jenky python script to manually jam the key into the XML file).
PS. I would have filed an issue over on your repo, but you haven't enabled issues.
DMJC
commented
1 month ago When you get the message, go to Facebook. It will ask if you tried to login. Select yes and remember browser. It then logs in and stays logged in. It never worked on my account before I implemented the bitlbee code two days ago.
On Tue, 17 Sept 2024, 8:49 am Phil Dibowitz, @.***> wrote:
@DMJC https://github.com/DMJC - I tried it... but I don't see how 2FA is supposed to work. It fails the same way the old one fails. It just says Login approvals are on. Expect a code to use for log in (406) and I can choose "Modify Account" or "Reconnect".
(I'm assuming when you say you implemented 2FA, you don't mean I still need to use my jenky python script to manually jam the key into the XML file).
PS. I would have filed an issue over on your repo, but you haven't enabled issues.
— Reply to this email directly, view it on GitHub https://github.com/dequis/purple-facebook/issues/518#issuecomment-2354195309, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFS2YZ6G4C2XAU5L2YRQVTZW5RQNAVCNFSM45CKIO72U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMZVGQYTSNJTGA4Q . You are receiving this because you were mentioned.Message ID: @.***>
jaymzh
commented
1 month ago That totally worked! Thanks.
One thing though is that all my chats are now just the FBID (number) instead of names...
Hey there! It's about time I accept that I am not going to give a fuck about this project anymore. I'm generally burnt out on open source and have zero motivation for facebook related plugins.
Not to sound too much like a job ad for an unpaid position but, what I would expect from a maintainer:
I'm also fine with like, handing it over to someone I trust a lot but doesn't have a lot of time / doesn't know a lot of C but takes a conservative approach on merging things.
A lot of PRs in the last few years are like "update this user agent slightly" and it kinda sucks but we can probably roll with that.
Additional things I would really like to see in a maintainer:
I would like unicorns too.
Honestly this reads like a "for exposure" unpaid internship ad that requires 20 years of experience with rust, typescript and fortran. Just, you know, please do some casual reverse engineering in your free time to benefit the interests of this megacorp.
The less cynical side of this and the only thing that kept me going for a while is: bitlbee, pidgin and friends are, essentially, accessibility tools, for a broader meaning of accessibility than just blindness (although we do have a bunch of blind users), but other less visible disabilities too. So uh, there's that?