16:00:19 <fjahr> #startmeeting 
16:00:19 <corebot> fjahr: Meeting started at 2026-02-12T16:00+0000
16:00:20 <corebot> fjahr: Current chairs: fjahr
16:00:21 <corebot> fjahr: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:22 <corebot> fjahr: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:23 <corebot> fjahr: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:24 <hodlinator> hi
16:00:26 <eugenesiegel> hi
16:00:27 <fjahr> #bitcoin -core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge dzxzg eugenesiegel fanquake fjahr furszy gleb glozow hebasto hodlinator instagibbs janb84 jarolrod jonatack josibake kanzure kevkevin laanwj LarryRuane lightlike l0rinc luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sliv3r__ sr_gi tdb3 theStack TheCharlatan vasild
16:00:27 <fjahr> willcl-ark
16:00:29 <pinheadmz_> yo
16:00:30 <achow101> hi
16:00:30 <dergoegge> hi
16:00:30 <janb84> hi
16:00:32 <hebasto> hi
16:00:33 <furszy> hi
16:00:33 <brunoerg> hi
16:00:34 <abubakarsadiq> hi
16:00:37 <stringintech> hi
16:00:38 <Sjors[m]1> Hi
16:00:39 <sliv3r__> hi
16:00:41 <fjahr> There is one pre-proposed meeting topic this week. Any last minute ones to add?
16:00:43 <sr_gi> hi
16:00:54 <lightlike> Hi
16:00:56 <johnny9dev> hi
16:01:03 <stickies-v> hi
16:01:14 <sipa_> hi
16:01:28 <sipa> hi
16:01:38 <fjahr> We'll get started with the WGs!
16:01:41 <fjahr> #topic Fuzzing WG Update (dergoegge)
16:01:52 <dergoegge> nothing from my side
16:02:00 <cfields_> hi
16:02:21 <fjahr> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:02:39 <sipa> Hi!
16:03:26 <sipa> We're getting very close to the finish line. #34257 was merged. Next to review is #34023 which would be good to get into the first release still.
16:03:28 <corebot> https://github.com/bitcoin/bitcoin/issues/34257 | txgraph: deterministic optimal transaction order by sipa · Pull Request #34257 · bitcoin/bitcoin · GitHub
16:03:30 <corebot> https://github.com/bitcoin/bitcoin/issues/34023 | Optimized SFL cluster linearization by sipa · Pull Request #34023 · bitcoin/bitcoin · GitHub
16:03:42 <sipa> I've removed some parts of the latter that are less critical, so ready for review now.
16:04:02 <sipa> That's it for me.
16:04:14 <fjahr> #topic Net Split WG Update (cfields)
16:05:12 <cfields_> nothing to report this week
16:05:36 <fjahr> I guess we are skipping kernel, silent payments and benchmarking unless I missed someone or they forgot to say hi...
16:05:57 <fjahr> #topic unbundling the GUI (https://gist.github.com/stickies-v/c871439db3ac93269d370905323820a8) (hebasto, stickies-v)
16:06:04 <hebasto> hi
16:06:07 <hebasto> I'm presenting this topic alone.
16:06:12 <hebasto> the updated is here: https://gist.github.com/hebasto/478910dc16239d17c8bfdfd61a53a5dd
16:06:18 <hebasto> it's a common opinion that the GUI development stuck.
16:06:23 <hebasto> but I see it a bit differently; it's in stalemate.
16:06:29 <hebasto> the current monolithic approach in the codebase, build system, release process, and publishing makes it infeasible to move forward neither in the current GUI (like adding Wayland support for release binaries) nor in new QML-based GUI.
16:06:34 <hebasto> this crisis stems from the natural antagonism between security (less dependencies) and functionality (more dependencies).
16:06:41 <hebasto> the problem with Bitcoin Core GUI has been known for quite a long time, and this attempt to find a solution isn't the first.
16:06:46 <hebasto> furthermore, the long-standing nature of this issue, combined with the separate GUI repository, led to a decline in developer focus on the GUI.
16:06:53 <hebasto> I strongly believe that it is in best interest of the current and _future_ users to shift focus on developing the GUI based on a public API (IPC, RPC etc).
16:06:59 <hebasto> of course, we have to pledge to develop and maintain such APIs basing on the best engineering practices.
16:07:04 <hebasto> as a side effect, it opens a free market for alternative GUI implementations.
16:07:08 <hebasto> the immediate action I propose is to deprecate the GUI binaries in v31.0
16:07:14 <hebasto> in light of the above, I will be shifting my personal focus accordingly.
16:07:18 <hebasto> that's all from me
16:07:53 <achow101> The gist states that the eventual goal is to abandon the GUI, which I wholeheartedly disagree with
16:08:56 <achow101> I think the project must ship an official GUI. That can still be done even if we have IPC
16:08:57 <johnny9dev> I would also like to add that from someone on the edge. The gui doesnt look abandoned at all. There are PRs and issues flowing. Its certainly slow but it appears infinitely more healthy than a majority of open source projects.
16:09:37 <hebasto> achow101: I hope you can propose an alternative to move away from the current stalemate?
16:09:40 <furszy> I think we should monitor the GUI's downloads in some way, and see if we do have users for it.
16:10:04 <pinheadmz_> furszy i suggested that before, no one wants to track bitcoin users tho
16:10:19 <furszy> not even the download count?
16:10:22 <pinheadmz_> also suggested we intentionally break the gui and see if anyone complains ;-)
16:10:30 <janb84> I like the free market idea
16:10:31 <pinheadmz_> furszy ask BlueMatt[m] hell refuse
16:10:35 <l0rinc> hi
16:10:36 <instagibbs> pinheadmz_ lol
16:10:55 <achow101> hebasto: I don't disagree with moving towards having a stable IPC interface that the GUI can use, but that does not mean that we shouldn't ship a GUI
16:11:01 <pinheadmz_> johnny9dev IIRC you have a branch of QML that is pretty good - but its like 1000 commits
16:11:02 <johnny9dev> there are plenty of people that I believe would be interested in taking ownership of the old gui as well. I wouldnt use the term deprecation but maybe migrating it is an idea.
16:11:06 <instagibbs> I'm a marginal GUI user, but I'd just as easily use an alterantive dashboard for the same purposes
16:11:10 <pinheadmz_> so if we want a gui we need review
16:11:10 <furszy> pinheadmz_: I had a few easy crash fixes in the gui open for a while, and no one complained about them.
16:11:27 <achow101> furszy: all access logs on the website are disabled so we currently can't get any stats
16:11:51 <dergoegge> Who ever wants us to keep shipping the gui will need to take care of it
16:11:52 <sliv3r__> @pinheadmz_ lol
16:12:15 <pinheadmz_> it does seem very useful to find out if anyone uses a thing before we dedicate work to it
16:12:17 <BlueMatt[m]> @libera_irc_pinheadmz_:bitcoin.ninja i mean, i think the gui is great to have, but also i dont really have an opinion that counts here cause I don't work on core
16:12:21 <fanquake> pinheadz: the issue with the current QML (which iirc hasn't had a commit for 6 months), is that is inherits the same architectural problems as the current gui, but somewhat worse, given the subtree.
16:12:23 <pinheadmz_> achow101 why do you think we must ship a gui ?
16:12:40 <fjahr> I can agree with the issue stated but by hebasto/stickies but if we don't have any official GUI at all I fear a flood of vibe coded malicious GUIs that will cause us more pain than maintaining an official gui, which could be very minimal
16:12:49 <pinheadmz_> BlueMatt[m] do you have an opinion about tracking downloads ?
16:12:53 <BlueMatt[m]> if bitcoin core is gonna ship a wallet, it seems reasonable that it should also ship a gui to access that wallet
16:12:57 <achow101> pinheadmz_: because users expect us to provide one. I think everyone severely underestimates how many people actually use the gui
16:13:02 <BlueMatt[m]> pinheadmz_: yes, we shouldn't do it.
16:13:21 <sipa> hebasto: i don't think the dependencies problem is core to the issue here; we can move towards a more-static-linked binary for bitcoind, and simultaneously toward a more runtime-dependency rich bitcoin-qt binary... because GUI users naturally depend on more dependencies (no pun intended)
16:13:30 <achow101> just for example, the default windows and macos downloads install and provide access to the gui by default. Using bitcoind on windows is a pain in the ass. and the macos app installer doesn't even provide bitcoind or the utilities
16:13:32 <pinheadmz_> fanquake all the commits are, i belive, on johnny9dev branch and need lots of PRs and reviews
16:14:03 <fanquake> pinheadz: is the subtreeing solved, and is it using IPC now?
16:14:15 <furszy> BlueMatt[m]: not even download count? nothing else.
16:14:34 <hebasto> fanquake: wdyt about sipa's suggestion?
16:14:37 <pinheadmz_> fanquake not using IPC yet
16:14:41 <eugenesiegel> to second fjahr comment, I also worry about malicious GUIs takings the official ones place
16:14:42 <fanquake> It would be good to get some clarity around if we are implementing new features (silent payments, pay dns, privatebroadcast, assumeutxo etc) in the current gui, and who might implement those
16:14:52 <achow101> something else to consider is that we already have a bunch of loud people who claim we hate users. killing the gui in the short term will add fuel to that fire
16:15:00 <pinheadmz_> i just wanted to stop core codebase changes in the qml repo, so forcing bitcoin as a subtree
16:15:05 <johnny9dev> I bet we could recruit people to work on those things if its a manpower issue
16:15:07 <dergoegge> there's nothing stopping anyone from building malicious GUIs right now
16:15:23 <sipa> hebasto, fanquake: to be clear, i'm not saying that this is a trivial thing to do - i'm saying the issue isn't dependencies, it's reviewer interest (if anything)
16:15:23 <hebasto> achow101: it's not about "killing the gui"
16:15:39 <ryanofsky> i'm curious about problems with the subtree. it seems like a read-only subtree could be a good way to support a group of external developers making a gui
16:15:40 <BlueMatt[m]> furszy: im not aware of a way to do counts trivially without logs on a static site. i mean you can log to tmpfs and then have a script that converts that to count, but then you do have logs...
16:15:46 <fjahr> dergoegge: but people are not actively looking for a replacement right now so the incentives are much lower
16:15:58 <pinheadmz_> johnny9dev -- your branch -- how is it going. feature complete? enough for most users to send and receive?
16:15:59 <achow101> dergoegge: the only people who would be affected by a malicious gui right now are those who seek a 3rd party gui. killing the official one requires every gui user to find one
16:16:33 <fanquake> ryanofsky: it doesn't decouple the gui from our repo, and doesn't properly exercise the interface, like an external user would have to
16:16:45 <fanquake> we can't clean up any code, we need to keep sharing depends in some awkward way etc
16:16:58 <fanquake> basically the current situation except worse, because now you have a sync / versioning problem
16:17:20 <johnny9dev> The branch is still in the demo state. I had personal things come up and other project take priority. I think conceptually your refactor works and it is a route to build the gui independantly but there is a lot of work to make qml a reality still
16:17:41 <fanquake> (also unclear if the CI framework would be shared, of the gui repo would have it's own)
16:17:46 <ryanofsky> fanquake, thanks. i feel like those issues might be fixable? like we could delete all gui code & depends stuff from core repo and move it to an external repo includeing core as a read-only subtree
16:17:50 <fanquake> which would retain further coupling
16:18:25 <fanquake> ryanofsky: how about all the settings code, util code etc?
16:18:55 <sipa> ryanofsky: i like that as something we could try, but i'm not sure it'll change much
16:18:57 <ryanofsky> it is includedin core. if gui developers need to change it (hopefully not frequently) they submit a pr
16:18:58 <johnny9dev> I do agree that the subtree refactor pinheadz did to the qml project is a viable alternative. Release process/ownership would need to be understood
16:19:09 <johnny9dev> doing that adds more process
16:19:22 <fanquake> Somebody should be able to take out IPC interface, and build a GUI essentially without seeing our repo, and we aren't dogfooding that by having a subtree with tonnes of shared code
16:19:39 <johnny9dev> agree there too. it would be a step in the right direction though
16:19:40 <ryanofsky> sipa, yes. i think the real question is just whether external developers want to continue maintaining the gui, but developers here who are currently maintaining it do not want to
16:19:43 <fanquake> and I assume would not build out the interfaces properly, because we can just cheat
16:19:51 <ryanofsky> s/but/because/
16:20:20 <dergoegge> achow101 fjahr: they've managed to download and run bitcoin-qt I think they'll be fine. Seems like very paternalistic thinking. They might also (more likely) find a better alternative
16:20:21 <achow101> I strongly prefer that we still have the gui in the main repo, shipped along with our normal release process. it can still use IPC and does not need to be so tightly coupled, other than in doing releases
16:20:23 <johnny9dev> I'm skeptical that the gui is in such a dire state, though. I know its been a friction point, but I don't fully understand why.
16:20:31 <fanquake> This just seems to create more friction, and repos to track, that non-gui devs (majority) have to deal with?
16:21:00 <BlueMatt[m]> yea, i mean the gui works fine. just because its not super actively maintained doesn't mean that it has noticeable bugs that impact the average user
16:21:01 <sipa> fanquake: that's fair - and cleaning up the interface to make it even possible to have an IPC-only GUI will probably require significant changes to the interface on the core side, so would be easier to do before such a subtree move
16:21:25 <ryanofsky> fanquake, moving gui code out of core into a separate repo would seem to create more friction for (theoretical) gui developers but not core developers
16:21:31 <Sjors[m]1> My hot take would be: we should keep offering a GUI, but it can a separate download. Designing a fresh IPC for this, rather than sticking to the current GUI interface, would make the most sense to me.
16:21:43 <fjahr> dergoegge: It will look much better and then maybe steal their coins
16:21:50 <Sjors[m]1> And I would probably feel more motivated to work on such an IPC interface than on the current GUI code.
16:22:23 <fjahr> dergoegge: And the users won't know which project stole them, core or the gui
16:22:33 <fanquake> ryanofsky: yea, the reason the separated repos seem to have worked so far, is because 95% of core devs aren't touching any gui code
16:22:51 <fanquake> (also why none of the GUI side of features we've shipped has been implemented)
16:23:02 <dergoegge> fjahr: if your core node is a hot wallet then any piece of software you download runs that risk
16:23:08 <fanquake> A non-technical user still can't use AssumeUTXO
16:23:11 <achow101> I would argue that separate repos has not worked so far, and is in fact what has caused the GUI to get into this stalemate situation
16:23:29 <sipa> achow101: i agree
16:23:39 <furszy> fanquake: would argue that a technical one neither.
16:23:45 <furszy> but that is a different subject
16:23:52 <fanquake> I think the key point here, is that hebasto has decided he's focussing on different things, so it sounds like somebody(s) need to step up here
16:24:06 <achow101> in fact, I would entirely propose that something we should try to unstick the gui is to remove the separate repo and bring it back into the main repo
16:24:30 <fanquake> As of today there are new (non-)GUI issues that needs solving, i.e #34569
16:24:31 <corebot> https://github.com/bitcoin/bitcoin/issues/34569 | build: Qt depends build broken with GCC 16 · Issue #34569 · bitcoin/bitcoin · GitHub
16:25:07 <cfields_> Oh, heh, I have fixes for that :)
16:25:14 <dergoegge> the proposal was abandonment in v34, all of you who are so in favor of having a gui have enough time until then to build an alternative we can ship that solves the current issues
16:25:20 <cfields_> I built wit gcc16 this week and have some patches to PR.
16:25:39 <cfields_> (I realize that's not the point you're making though.. )
16:25:47 <pinheadmz_> fanquake is right the real lede here is hebasto's priorities
16:25:58 <sliv3r__> achow101 I agree, it's so anoying if you try to do stuff on the gui to have another repo with a bunch of duplicated code
16:26:31 <fanquake> Yea. Someone else needs to be responsible for release prep, translations, implenting new GUI features, making a decision about QML, deciding what new GUI features we might implement, make a decision about a wayland migration or not, etc
16:26:32 <hebasto> fanquake: pinheadmz_: I don't think its about my personal priorities
16:26:41 <achow101> dergoegge: I am doubtful that we can do all of multiprocess in that time, which seems like a hard requirement for alternative guis
16:26:49 <johnny9dev> To the point of bitcoin-core/gui being not create. I still don't actually know the relationship between bitcoin-core/gui and bitcoin/bitcoin. I've been on the edge but I think it probably be obvious to someone like me by now.
16:26:57 <johnny9dev> being not great*
16:27:32 <dergoegge> The RPCs work as well, there's no hard requirement on IPC afaict
16:27:56 <dergoegge> Alternative decoupled GUIs exist today without IPC
16:28:00 <achow101> dergoegge: there absolutely is, in order to get signals/notifications
16:28:01 <Sjors[m]1> RPC is much too slow for a UI, all of the web based UI's have demonstrated that
16:28:08 <achow101> dergoegge: provide an example
16:28:22 <dergoegge> liana, specter, sparrow
16:28:31 <achow101> none of those are guis. those are whole ass separate wallets
16:28:51 <sliv3r__> those does not allow you to control your node
16:28:56 <achow101> they do very different things from what our gui does
16:29:08 <hebasto> re "Yea. Someone else needs to be responsible for release prep, translations, implenting new GUI features, making a decision about QML, deciding what new GUI features we might implement, make a decision about a wayland migration or not, etc" -- okay, if you say so
16:29:32 <fanquake> ? Isn't that what you're proposing by focussing on other things?
16:29:35 <johnny9dev> yeah if you're serious i think you need to champion a new owner and mentor
16:29:38 <dergoegge> RPCs can be polled
16:29:38 <johnny9dev> it will be a lot of work
16:29:44 <pinheadmz_> boy it sure would be great is we knew any users wanted a bitcoin core gui
16:29:51 <pinheadmz_> how can we set our agenda without that info
16:30:01 <BlueMatt[m]> I mean people definitely use it
16:30:06 <sipa> agreed, achow101; and importantly: there is no way to convert/import/load Bitcoin Core wallets into them - they have an entirely different idea of what a wallet is, so that's no viable migration path for current GUI wallet users
16:30:15 <Sjors[m]1> I use it :-)
16:30:17 <BlueMatt[m]> how man i dunno, but its very far from zero, and with a wallet its the most important part
16:30:42 <pinheadmz_> good point - abandon the wallet !
16:30:47 <achow101> pinheadmz_: here's data from the survey I ran 5 years ago, never really processed it to the point that something could be written up, but there were questiosn about how users use Bitcoin Core https://github.com/achow101/2021-core-survey/
16:31:19 <sliv3r__> if we kill the gui we kill the posibility for non-tech users to run nodes easily without relaying on something like umbrel, etc.
16:31:50 <achow101> of the 342 people who responded to the question "How do you currently use Bitcoin Core?", 176 of them said "the GUI"
16:32:02 <pinheadmz_> interesting !
16:32:02 <sliv3r__> people should be able to run a node only with core, and not needing other's "frontend" software
16:32:24 <achow101> of the 387 people who responded to the question "how did you previously use Bitcoin Core?", 246 responded "the GUI"
16:32:52 <sliv3r__> achow101 would be a lot of work to run that survey again?
16:33:11 <dergoegge> So the only data we have is a 5 year old survey of ~400 users?
16:33:15 <sipa> sliv3r__: i worry that the current social media climate is not conducive to getting honest answers
16:33:18 <achow101> sliv3r__: kinda yeah, and also the questions need major work to get more useful info out
16:34:08 <sliv3r__> true :/
16:34:21 <achow101> dergoegge: the survey itself had ~3000 responses, just those ~400 who answered those specific questions
16:35:22 <ryanofsky> i think it'd be good to have a more specific idea of current problems. if hebasto, fanquake others are currently spending time on the gui and want to work on other things, deleting src/qt/ may be one solution but there may be others
16:35:23 <pinheadmz_> well could we start releasing a QML-beta within a year that had MVP functinality
16:35:27 <pinheadmz_> along with deprecating Qt
16:36:03 <dergoegge> Who will work on the qml gui?
16:36:34 <johnny9dev> as the last remaining QML guy. I actually think the Qt widgets serves a really important role and I have grown to really like it.
16:36:50 <hebasto> I will
16:36:52 <johnny9dev> I would rather keep Qt widgets alive than try to replace it.
16:36:52 <pinheadmz_> well. i can take on some of the review to get jonnys work into a beta release.
16:37:39 <pinheadmz_> the qml ui looks slick and modern, i think it is something bitcoin should have
16:37:41 <sipa> johnny9dev: just for someone not familiar with the terminology... does "Qt widgets" mean the current non-QML gui?
16:38:00 <hebasto> ^ right
16:38:01 <furszy> sipa: the current widgets
16:38:05 <johnny9dev> yeah qml serves a different purpose that the widgets one for sure and there is a lot of opportunity if it can be realised
16:38:20 <sipa> furszy: you have not provided an answer that is useful to someone unfamiliar with technology :p
16:38:23 <johnny9dev> Qt widgets is old-school desktop gui
16:38:27 <sipa> *terminology
16:38:31 <johnny9dev> think tables, gray buttons, and tabs
16:38:35 <furszy> sipa: :)
16:38:51 <achow101> sipa: QT widgets is what the current gui we ship uses
16:38:55 <johnny9dev> but its still perfect for data software. Sparrow is widgets based
16:38:58 <sipa> achow101: thanks
16:39:15 <pinheadmz_> isnt Qt deprecating widgets? like isnt there some dependency-reason we have to migrate ?
16:39:19 <johnny9dev> no they are not
16:39:28 <johnny9dev> there was a misconception but it will never be deprecated
16:39:36 <pinheadmz_> ah i was misconcieved
16:39:47 <johnny9dev> its not getting new features but it is supported. Consider it "solved"
16:39:56 <hebasto> Qt stopped developing Qt Widgets actively, but not deprecated them
16:40:43 <furszy> so, hebasto, you are interested in working on the new GUI, but not in maintaining the current one anymore?
16:41:25 <Sjors[m]1> If QML is easier to work with and we have a working prototype, that's still better(tm), no?
16:41:45 <fanquake> ryanofsky: 1 issue is that because the QML gui was being built, no new features were added to the current GUI, but that has also stalled, so now new features are being added anywhere
16:41:55 <sipa> it is not just a question of what technology is best, but also what people want to work on, sadly
16:42:15 <sliv3r__> Is there any tracking issue or resource that lists the implemented and missing features for both new and old GUI?
16:42:20 <fjahr> sipa: so rust gui?
16:42:34 <sipa> fjahr: can you vibecode that?
16:42:53 <fjahr> sipa: consider it done
16:43:07 <achow101> fjahr: if it can work over ipc, i don't see why not
16:43:14 <cfields_> fjahr: that becomes an actual possibility if good ipc api emerges...
16:43:34 <johnny9dev> it would also be good to get an understanding of what would make developing the current gui more manageable or why it feels like its such a burden
16:43:37 <achow101> as long as others are okay with us shipping it under the bitcoin core banner
16:43:51 <dergoegge> is the need for IPC actually documented somewhere? don't see why that is such a hard requirement
16:43:57 <hebasto> furszy: I was saying not about my intetntion but about what I believe is good for the users and developers
16:44:36 <hebasto> important detail that QML-based GUI was designed by designers
16:44:43 <achow101> dergoegge: I don't believe so
16:45:07 <dergoegge> Can it summarized quickly here?
16:45:19 <Sjors[m]1> dergoegge: IPC has the potential of actually being acceptably fast for a UI
16:45:48 <Sjors[m]1> Although we probably won't get 120 frames per second on mobile :-)
16:45:51 <achow101> but just as a (very) old example, armory resorted to reading the blocksdir rather than relying on rpc
16:46:02 <sipa> i think the IPC relevance here is just that if we'd force our own GUI to use the IPC, we'll necessarily also make it easier for external projects to build their own GUI against the same interface
16:46:05 <achow101> because rpc was slow to respond
16:46:15 <Sjors[m]1> Regarding rust and IPC: that's being very actively tested for the Mining interface.
16:46:22 <achow101> and rpc polling just kinda sucks
16:46:50 <sipa> i don't think RPC for a GUI is all that interesting; it's not great for it - and making a good RPC GUI interface is probably harder than creating an IPC interface from scratch + GUI from scratch that uses it
16:46:51 <Sjors[m]1> And with libmultiprocess using IPC for a c++ client is a piece of cake.
16:46:52 <dergoegge> RPC is not slow anymore
16:47:09 <dergoegge> as in the json-rpc overhead is not noticeable if you click a button
16:47:17 <achow101> and rpc did not (does not?) provide all of the necessary data
16:47:21 <furszy> hebasto: I think we are in a similar spot to when we were doing the projects board and voting for them. Everyone who feel this is important should sign up to work on it. Otherwise we will stall again.
16:47:29 <dergoegge> what data is missing
16:47:43 <dergoegge> we can add that and it'd be less work than all of IPC
16:47:48 <Sjors[m]1> Adding data to RPC shouldn't be the bottleneck.
16:48:13 <achow101> don't remember off the top of my head, it's been 10 years
16:48:16 <fjahr> johnny9dev: Would it be fair to say that the QML project is suffering from too high expectations and that is hindering it getting towards the finish line? E.g. if you were not trying to achieve everything exactly as in the design docs would you be done quicker?
16:48:34 <Sjors[m]1> But in the UI you often need push based stuff, like a notification when a transaction confirms. You can do that with multiple long poll RPC requests, but it's cleaner with IPC.
16:49:34 <dergoegge> Why does polling suck? because it's not optimal from a eng perspective? I don't think users would care
16:50:04 <fanquake> fjahr: I think the expectations are just to implement the features we currently have, so it'd be a drop-in replacement?
16:50:15 <hebasto> fjahr: once we agreed on the including more dependencies guix scripts without sacrificing security of bitcoind, the QML-based GUI could be released in v32.0
16:50:47 <dergoegge> achow101: so perhaps it's not even an issue? the wallet and node work just fine through the cli, so I don't see how RPCs  wouldn't be good enough for a gui
16:51:04 <achow101> but the general issue is that the gui wants to be notified/get a signal when things like a block or transaction arrive to the wallet that needs to be shown to the user. for something like transactions, there's no way to ask rpc essentially "what has changed since I last polled", but rather it has to be "give me all of the wallet transactions and then I need to diff this response with the last one"
16:51:33 <hebasto> ^ right
16:51:34 <sipa> dergoegge: i think these are questions that need to be answered by people working on the GUI, not in this meeting
16:51:36 <achow101> and then we also run into limitations like listtransactions doesn't return all tranasctions, and asking it to do that every time can actually be quite slow
16:51:36 <fjahr> fanquake: but it also has this beautiful UI that was designed and I guess that adds overhead
16:51:47 <dergoegge> All I'm saying is that if people want to build a nice gui today, it is possible. It's just that almost no one wants to actually do the work
16:52:02 <fanquake> fjahr: sure. It has also been 4 or 5 years though?
16:52:28 <achow101> dergoegge: probably because there is currently a gui, so why work to create something that's worse
16:52:29 <fjahr> fanquake: yeah, just looking for potential shortcuts to the finish line ;)
16:52:36 <sipa> dergoegge: it's possible, but i think that's an unfair conclusion
16:53:35 <fjahr> (I also don't know if the original design get's further changes, the design community is quite active)
16:53:39 <fanquake> I guess if there's a heap of devs here who haven't contributed to QML in the last 4-5 years, but would like to actively work on it now, and that means we ship it in 32, and replace that current widgets based GUI, that is some clarity. Is that possible?
16:54:05 <achow101> fanquake: does it need to use IPC?
16:55:15 <fanquake> I think that would be best (even if that means it takes longer), otherwise we haven't improved things architectural, or started building what is needed for external applications to build the same type of applications
16:55:22 <hebasto> QML GUI for 32.0 may be based on internal interfaces only
16:56:04 <Sjors[m]1> What hebasto says makes sense to me. Once we have QML, we can redesign the interface and then later make it public facing.
16:56:11 <achow101> fanquake: sure, but doing that requires us to actually finish doing multiprocess
16:56:30 <achow101> which seems to be currently focused a lot more on supporting mining
16:56:34 <fanquake> achow101: only to the extent that we have done for the mining interface right? Given that is currently shipped and useable
16:57:02 <fjahr> 3 minutes left...
16:57:20 <Sjors[m]1> We've made quite a bit of progress on fine-tuning libmultiprocess since v30.
16:57:36 <sipa> i think being restricted to clean internal interfaces is 90% of the work of making it IPC-capable?
16:58:19 <Sjors[m]1> sipa: not necessarily, IIRC there's some stuff that doesn't perform well with the IPC overhead.
16:58:25 <Sjors[m]1> So that needs to be redesigned.
16:58:41 <achow101> fanquake: I think it'll be more complicated? it will have to launch bitcoind in the background and do process management stuff?
16:58:51 <hebasto> Sjors[m]1: due to latency?
16:59:12 <Sjors[m]1> hebasto: probably due to going back and forth too much. But this hasn't been tested recently.
16:59:20 <sipa> ok fair
16:59:35 <fjahr> Anything else that needs to be shared? Feature freeze is in 2 weeks.
16:59:36 <Sjors[m]1> We also left out process spawning for mining, so that's not battletested.
16:59:58 <achow101> I think we should defer the action of deprecation to after we can yell at each other in person
17:00:06 <fjahr> (feel free to continue the GUI discussion of course but I will finish the meeting)
17:00:18 <pinheadmz_> The gui discussion will never end
17:00:24 <fjahr> #endmeeting