< bitcoin-git>
bitcoin/master 9bdde3c eugene: build: add /usr/local/ to LCOV_FILTER_PATTERN for macOS builds
< bitcoin-git>
bitcoin/master 2d4574a fanquake: Merge #19861: build: add /usr/local/ to LCOV_FILTER_PATTERN for macOS buil...
< bitcoin-git>
[bitcoin] fanquake merged pull request #19861: build: add /usr/local/ to LCOV_FILTER_PATTERN for macOS builds (master...macos_lcov_0902) https://github.com/bitcoin/bitcoin/pull/19861
< luke-jr>
achow101: even over Tor?
< achow101>
doing it over tor would have a number of attached issues, like the fact that we would need to package tor with the binary and then start it up
< achow101>
but I think just the idea in general would scare away many privacy conscious people
< luke-jr>
hmm
< achow101>
sure it isn't telemetry, but it's pretty close
< luke-jr>
you want close? "you just used a feature we don't think anyone uses. want it to remain usable? please send us an email about what you used it for!" :P
< vasild>
why "but relay to some extent to the level (2) ones in addition to that" ?
< vasild>
why care to relay to (2)?
< vasild>
if (2) guys care/want/need addr messages, they can always ask for it themselves via getaddr, no?
< sipa>
vasild: well that's the point, i argue we shouldn't have (2)
< vasild>
I agree
< vasild>
I think it should be just two options: "I want" and "I don't want" unasked addr messages
< vasild>
because if it is known that implementations prefer to relay to (3) over (2), or relay more to (3), then a (2) relay has incentive to pretend to be (3)
< sipa>
vasild: my worry is the opposite- an attacker who wants to learn your connectivity could connect many times, as (2)
< sipa>
because we'd uniformly relay to all (3)s, but then in _addition_ still relay to (2) giving them a better than proportional view of our activity
< sipa>
(i'm hypothesizing about how (2) would work here, of course, as it doesn't exist and imho shouldn't exist... but i can't imagine any other useful rhing to do with it)
< vasild>
so, two distinct reasons to have just two options - (1) and (3) ;)
< sipa>
right
< vasild>
From Gleb's email: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017428.html "I want to suggest making explicit whether a node promises to participate in address relay by a) forwarding unsolicited messages (I work on a somewhat related issue in this PR [2]) , and, b) responding to GETADDR."
< vasild>
I have been wondering if those two deserve a separate BIP or should be sneaked into BIP155
< vasild>
that a) should be "I want / I don't want unsolicited addr messages"
< vasild>
and maybe b) deserves a service bit so that nodes that plan to ask GETADDR from their peers can chose to connect only to such peers (rather than discover that the peer they already connected to cannot reply to GETADDR)
< vasild>
it would be undesirable to have some SPV client connect-disconnect in a loop until they find a node that can reply to getaddr
< vasild>
Maybe a) can be sneaked into BIP155 as a boolean flag to sendaddrv2 and b) done outside of BIP155 via a service bit?
< sipa>
vasild: well is there any software right now that one may xonnect to that can't respond to getaddr?
< vasild>
I am not 100% sure, but I gather that SPV nodes don't keep an addr database, so maybe they are such ones?
< sipa>
you also can't connect to them
< sipa>
they only make outbound connections afaik
< vasild>
hmm, then maybe "b) responding to GETADDR." is not needed? I am not familiar enough to judge, Gleb?
< gleb>
vasild: I think I wanted to emphasize while b) is always true (I guess?), a) is something that may wary. You are right that my sentence has redundancy. It may be reduced to "whether a node promises to participate in forwarding unsolicited messages".
< vasild>
I se
< vasild>
e
< sipa>
f
< fanquake>
g
< gleb>
Does anyone know why we have "Add small amount of random noise before connection to avoid synchronization" when connecting to feelers? There is already a randomized (poisson) interval between creating feelers, so this seems unnecessary?
< gleb>
I privately messaged ethan on irc, but he didn't respond
< bitcoin-git>
bitcoin/master 6de9429 nthumann: qa: Changes v0.17.1 to v0.17.2
< bitcoin-git>
bitcoin/master 4053de0 Wladimir J. van der Laan: Merge #19859: qa: Fixes failing functional test by changing version
< bitcoin-git>
[bitcoin] laanwj merged pull request #19859: qa: Fixes failing functional test by changing version (master...qa-fix-wrong-version) https://github.com/bitcoin/bitcoin/pull/19859
< sdaftuar>
gleb: i had that same question myself recently! i agree with you that it seems unnecessary
< sdaftuar>
wumpus: i think #19670 is close to mergable as well? i'm not sure if anyone else is planning to review, but it has a few ACKs and user reports it fixes a bug
< wumpus>
two proposed topics for this week: conducting a large scale usage survey (achow101), Bitcoin Design Community and efforts around the Bitcoin Core project (moneyball)
< amiti>
hi
< wumpus>
any last minute things anyone wants to discuss?
< luke-jr>
(well, obviously I did *look at* the code, but not enough to ACK it)
< ajonas>
I'm unclear what that means in this case
< luke-jr>
maybe close enough I should just finish the review tho
< wumpus>
ajonas: I think it's in there mostly to give the discussion there visibility (which is what that colum is for, even if it's not strictly about a concept ACK)
< ariard_>
ajonas: actually we could swap it by #19820 first, as any package relay discussions should fall under this one first IMO
< aj>
wumpus: it's been there a long time now, and don't think there's current progress on it (and maybe better served by the p2p meetings for now anyway?)
< wumpus>
I think we can go on to the other topics
< wumpus>
#topic conducting a large scale usage survey (achow101)
< achow101>
I wanted to get some opinions on the feasibility and usefulness of conducting a usage survey
< jonasschnelli>
smells after a drama maker. :)
< bitcoin-git>
[bitcoin] ariard closed pull request #19147: Document discouragement logic with regards to malicious exploitation (master...2020-06-doc-banman-infra) https://github.com/bitcoin/bitcoin/pull/19147
< achow101>
the idea for the survey is to get data on how people use Core. particularly, for the wallet, we want to know things like if anyone uses things like zapwallettxes
< jeremyrubin>
I think it's a great idea!
< jeremyrubin>
I've appreciated your twitter questions
< jeremyrubin>
and I've done some similarly; would be cool for it to be a bit more buttoned up with ability to follow up with users
< moneyball>
Square Crypto just announced a user research grant to Jamaal who is an experienced research from OMI and IDEO, to exclusively focus on Bitcoin Core, so it seems like that would be a great person to engage on this
< jonasschnelli>
I think it's a great idea. Unsure how to execute practically
< wumpus>
I was okay with remiving zapwallettxes but I dislike how it seems we're removing all recorvery functionality
< moneyball>
but he is eager to work with Core developers on improving it and making it as impactful as possible
< wumpus>
it's clear such things are useful sometimes even if people don't use them a lot day to day
< sipa>
moneyball: please wait for topic?
< moneyball>
sipa: I am responding to achow's call for a usage survey
< luke-jr>
sipa: this is the topic
< sipa>
oh, oops!
< moneyball>
We now literally have an expert at this :)
< achow101>
wumpus: i'm not necessarily trying to remove recovery functionality
< ariard_>
moneyball: you should ping folks from blockchain commons, IIRC they have thoughts on how to improve core wallet
< wumpus>
in any case, more generally, I don't think doing a survey can hurt
< achow101>
but also I think a survey could also get us some useful data for other things
< jeremyrubin>
I'm not positive that lack of expertise is the issue. E.g., I'm a published HCI author and I know other people have similar expertise. I think the broader issue is coming up with agreement that the results of such a survey would be actionable.
< nehan>
DCI has also been talking to a user research team. I think it can be tricky to design these surveys well, for example so you don't just hear what you want to hear
< moneyball>
Ok let me re-state: we have someone who will be dedicated full-time to this for 6 months, so I encourage anyone interested in shaping and influencing his research to connect with him
< moneyball>
His email is jamaalmonty [at] gmail.com
< luke-jr>
sounds like lots of different people trying to do a survey
< luke-jr>
I suggest they all work together :p
< jonasschnelli>
Just a little warning: some users don't know what they want (especially when it hits the privacy layer).
< nehan>
we have not started anything yet, just offering up information. will ask them to reach out to jamaal!
< jeremyrubin>
achow101: I think maybe what might make sense is to come up with some key issues we want to fix but don't know how to fix.
< moneyball>
nehan: great!!
< jonasschnelli>
Probably also hard to find samples that are representative for "the usergroupe" of Bitcoin Core
< jeremyrubin>
it sounds like wallet recovery is a real issue
< luke-jr>
I don't know we have a reliable way to contact all or even a good sample of users
< achow101>
jeremyrubin: right
< achow101>
the kind of data I'm looking for is more of what things are being used
< luke-jr>
I expect people who read bitcoincore.org, or the announcements list, etc are the same niches
< achow101>
I spoke with Jamaal and he's doing more on user experience stuff which is more subjective
< jeremyrubin>
achow101: you know the whole bullet holes on plane wing issue right?
< achow101>
jeremyrubin: yes
< jeremyrubin>
:)
< jonasschnelli>
Yes. UX and feature uses are two different things
< luke-jr>
a lot of users haven't upgraded since <0.18 still
< jeremyrubin>
I think what might be nice would be to start with a project-wise survey
< luke-jr>
(40%)
< achow101>
But if we're debating whether to remove e.g. zapwallettxes, it would be nice to know whether people use this
< jeremyrubin>
Rather than talking to end-users, start by talking to mid?-users
< luke-jr>
jeremyrubin: very different kind of users
< jonasschnelli>
achow101: how would you get representative samples to acctually use this as a decision base (to remove zap)?
< achow101>
other data I'm looking for though is number of UTXOs (within orders of magnitudes, not actual numbers), and wallet versions
< nehan>
achow101: is there a list i could share of your questions and thoughts?
< achow101>
jonasschnelli: I think the best we would be able to do is to promote the survey in as many places as possible. like put it on reddit, bitcointalk, twitter, etc.
< jeremyrubin>
luke-jr: that cluster of users is probably just more useful in early on work at having users who can clearly express what they want v.s. end users where the question becomes more of a UX endeavor IMO
< achow101>
nehan: not yet
< jonasschnelli>
The survey will probably be anonymous. So its super hard to tell wether one person did fill up 10k forms or 10k users filled out one form.
< luke-jr>
jeremyrubin: but they'd also already be opening PRs for what they want
< jeremyrubin>
That's not true
< sipa>
achow101: one issue especially with recovery options is that they're extremely rarely used features to begin with
< sipa>
achow101: and even if 99.99% of users never touch them, they are worthwhile
< jonasschnelli>
There will always be large questionmarks wether the gathered data is useful due to the nature that we don't do CRM
< achow101>
jonasschnelli: yes, that's certainly a problem. I think the best we could do there is to put a captcha and ask people not to be assholes
< sipa>
which means you need an extremely large and representative sample
< luke-jr>
back when I did the KYC poll thing, it matched Twitter polls pretty closely
< wumpus>
sipa: that was also my point, i think a survey is good for some things, but probably not for recovery options
< luke-jr>
so I don't think there's a whole lot of effort into skewing polls
< sipa>
wumpus: agree
< achow101>
wumpus, sipa: I agree that for recovery options, it's not as useful. But asking whether people have heard of the option might be.
< sipa>
achow101: agree
< jeremyrubin>
You can also make a survey only show a follow up if they check a box that they used it or lost a wallet
< jeremyrubin>
which if you just don't collect enough data on, you ignore it
< wumpus>
if it is about a single option, it's likely better to ask it separately on twitter than do a survey, will reach more people
< sipa>
"How many BTC have you lost due to unrecoverable wallet.dat files?"
< jeremyrubin>
heh
< achow101>
I think there would end up being a lot of questions like "have you heard of X?" followed by "If yes, have you ever used X?"
< jeremyrubin>
achow101: I think we can probably between some set of people also pay to promote the tweet?
< jeremyrubin>
if you want more respondents
< luke-jr>
inb4 a bunch of lost bitcoins get recovered as a result of said survey
< nehan>
there is also depth vs. breadth: it might be useful to interview 2-3 people who have lost btc to find out what went wrong
< jeremyrubin>
but in my experience polls get very high engagement
< jeremyrubin>
like usually at least 200 ppl
< jeremyrubin>
hey!
< jonasschnelli>
If a survey happens,.. i think the form how it's done (google forms, etc.) and what branding, originator/sender is used, privacy in general, etc. is used if very important to prevent people freaking out
< jeremyrubin>
Lots of people from the MIT Bitcoin Project lost their wallet.dats
< jeremyrubin>
can shoot the participants an email nehan
< achow101>
jonasschnelli: that's definitely a concern. I don't think any existing survey sites don't have tracking
< achow101>
we'd likely have to run something ourselves
< jonasschnelli>
Those details are the reason why I said at the beginning it is probably a "drama maker"
< jeremyrubin>
the issue is that then you bias onto people who will visit mysketchypoll.info vs. google forms :)
< achow101>
put it on bitcoincore.org
< jonasschnelli>
And I bet some BCH morons will script 10k survey submissions just to show off
< gwillen>
achow101: it's hard to guarantee anything doesn't have tracking, I have suggested to people that they just fill out google forms over Tor if they care a lot
< achow101>
mysketchpoll.bitcoincore.org :)
< sipa>
jeremyrubin: lol, i could have predicted that :)
< gleb>
blinded proof of ownership to participate? :)
< gwillen>
(I guess perhaps some non-google provider might be less likely to give Tor users lots of annoying captchas)
< wumpus>
agree w/ regard to drama maker, especially if you ask about people losing money you have to do with some care
< gleb>
poodle-style construction may help? not sure, should re-read it
< jonasschnelli>
And maybe you can argue that the most Core powerusers (which we actually want to sample) are generally not filling out surveys.
< jeremyrubin>
I think I'll re-make my suggestion that rather than doing an initial broad scope survey, we should build some experience on a couple smaller scale ones
< ariard_>
gleb: it's 2020, just ask them to pay a LN invoice :p
< wumpus>
at least for a public survery, if you're just going to interview a few people it's less of an issue
< jeremyrubin>
And then leverage that learning for future work
< achow101>
gleb: that would severely bias our sample to people willing to jump through the hoops
< wumpus>
heh, getting reliable statistics in 2020
< instagibbs>
what's the budget for this? :)
< jonasschnelli>
maybe it's best done outside of the core "official" channels (bitcoincore.org) and best put under your own umbrella (achow, twitter, your website)?
< sipa>
put it on the blockchain
< jonasschnelli>
instagibbs: budget is always 0
< * jeremyrubin>
I lost my wallet.dat because the blocks were too small to upload it.
< achow101>
I could setup a google doc where we discuss what and how to ask questions.
< instagibbs>
jonasschnelli, I am personal friends with survey researchers/professionals :P
< nehan>
achow101: +1
< achow101>
instagibbs: My budget is like $20
< jonasschnelli>
should be enough for 1m of a VM
< instagibbs>
s/friends/wife/
< instagibbs>
I'll sak her
< instagibbs>
ask
< jonasschnelli>
don't sak her!
< luke-jr>
…
< luke-jr>
instagibbs: you are a survey researcher's wife?
< jeremyrubin>
Those responsible for the survey have been sacked.
< instagibbs>
luke-jr, i no english sorry
< luke-jr>
XD
< jeremyrubin>
Anyways -- I think there's broad conceptually agreement on a survey achow101?
< achow101>
jeremyrubin: welp
< achow101>
yeah, i'll come up with a slightly more concerte proposal
< jonatack>
data point of one: i don't fill out surveys ever
< jonasschnelli>
achow101: thanks!
< sdaftuar>
by induction...
< jonatack>
due to google forms, tracking, etc.
< jeremyrubin>
jonatack: you just answered a survey on taking surveys
< luke-jr>
Sometimes I do if they're quick
< jeremyrubin>
So I think maybe a good next step would be to make a google doc and just let people add questions they want asked?
< luke-jr>
if they say 15 minutes, I just close it
< jeremyrubin>
Then trim it down into something more concrete
< moneyball>
We had an amazing response with over 500 designers and creatives from around the world joining the community. Some of them have an interest in contributing to the Bitcoin Core project.
< moneyball>
I already mentioned Jamaal's project above which is one touchpoint with the Core project.
< moneyball>
If interested, feel free to join these and engage. Note that there is not an expectation Core contributors must join these discussions, and as I state here (https://github.com/bitcoin-core/gui/pull/79#issuecomment-686613427), any formal proposed changes and discussion should occur on GitHub per the existing process.
< moneyball>
I think this is great news to have designers and researchers interested in helping the Core project! I am sure there will be a few areas to improve as we add new types of contributors, so don't be afraid to provide feedback or offer suggestions.
< moneyball>
Comments?
< luke-jr>
moneyball: why can't they use IRC, or at least the existing Core slack?
< wumpus>
moneyball: great to hear
< jonasschnelli>
Yes. Great to hear.
< moneyball>
They could, but most designers are not on IRC, but we are working to get them more comfortable with GitHub, which I think is going well.
< wumpus>
getting people to use IRC is kind of out of scope I think
< wumpus>
it's got to be more about what is being discussed than where, anyway
< jeremyrubin>
I think one question I have is the extent to which it makes sense to, assuming we have this massive influx of design talent, to work on the existing GUI or to gut-rennovate it. Not sure what's in scope
< instagibbs>
provided larger scale coordination is done at github level I don't think it should cause many issues
< jonasschnelli>
One first think that pops into my head when I hear designers working on Core: how hard will it be to adapt a flexible design with our native platform Qt approach
< luke-jr>
moneyball: they can join IRC just as easily as joining some new Slack
< jeremyrubin>
jonasschnelli: +1 similar q
< wumpus>
that's why QML was brought up, it's much more flexible in that regard
< hebasto>
jonasschnelli: by moving to QML?
< jonasschnelli>
So whatever comes out of the design process,... implementing it will be a challenge.
< jonasschnelli>
I agree with QML.
< wumpus>
there's only so much you can do with widgets
< jonasschnelli>
Which _is_ hard to switch towards
< jonasschnelli>
Also,... should the GUI still respect color patterns of the OS (dark mode, etc.)?
< wumpus>
someone already did some stuff with QML and bitcoin core in a PR for android
< hebasto>
is it acceptable to have hybrid (widgets + QML) binaries at somepoint?
< luke-jr>
the GUI low-level design (colours, widgets, etc) should be entirely determined by the OS
< jonasschnelli>
I think QML could be the right direction. Just,... that not an easy step by step transition probably
< jeremyrubin>
How far along is the splitting of wallet process stuff?
< wumpus>
I'm not sure they can be combined in one UI (or whether that makes sense)
< jonasschnelli>
Maybe the design process leads to a new UI...
< jeremyrubin>
Is it feasible that e.g. different GUIs can link to the same intefaces?
< wumpus>
in any case we'd need someone that knows how to use QML
< sipa>
luke-jr: you must hate websites :)
< wumpus>
jonasschnelli: yes, maybe eventually
< luke-jr>
sipa: I used Konqueror as long as it was viable ;)
< wumpus>
I think starting with a "mobile GUI" for core would be good
< wumpus>
just leave the current one for desktop for now
< jonasschnelli>
luke-jr: that would be impossible for designers to work with "(colours, widgets, etc) should be entirely determined by the OS".
< jeremyrubin>
that makes sense to me too; and is something familiar to designers these days (mobile first!)
< yanmaani>
as a user, I really hate QML
< wumpus>
which is also the PR I linked
< luke-jr>
jonasschnelli: then they're bad designers… :/
< yanmaani>
I really like it when it has a native look, like Core or, arguably better, Electrum
< jonasschnelli>
yanmaani: on what platform? Desktop?
< wumpus>
qt widgets is more or less unusable on mobile platforms so it's the first application anyway
< yanmaani>
Monero has a QML gui, and that looks horrible
< yanmaani>
jonasschnelli: yeah
< yanmaani>
mobile is different, but nobody (I hope) runs a full node on their phone
< luke-jr>
yanmaani: does QML mean non-native? :/
< wumpus>
people definitely run full nodes on their phones and tablets these days
< jonasschnelli>
QML means non native widgets
< yanmaani>
luke-jr: Think of QML like knock-off HTML for GUI development
< yanmaani>
Try using the Monero GUI, it looks like a website or something
< luke-jr>
NACK QML then :<
< wumpus>
this is not going to lead anywhere
< jonasschnelli>
QT provides some QML basic widgets. But they don't feel like your OSes widgets. Similar to using web-based applications like slack, etc.
< yanmaani>
I don't have much clout here but I think you should definitely stay native
< luke-jr>
wumpus: if the direction is bad, best to not follow that lead?
< jonasschnelli>
I guess there are good and bad native desktop apps as they are good and bad QML desktop apps. It probably depends on how it's made
< luke-jr>
jonasschnelli: by definition, if it doesn't use native widgets, it is bad. So if you're saying QML means non-native widgets, they are necessarily all bad?
< sipa>
luke-jr: that's your opinion....
< wumpus>
this is not going to lead anywhere? start with a mobile GUI
< jonasschnelli>
luke-jr: that's only your opinion
< jonasschnelli>
agree.
< moneyball>
these are the types of discussions that i'd love to have designers engage with existing Core contributors. discussion on GitHub is one common ground. if there is interest from Core devs to join the biweekly video calls, already hebasto and a few others do, and you're very welcome to that.
< wumpus>
leave the current one for desktop for now
< jonasschnelli>
I just repeat my first answer to this topic: [21:46:00] <jonasschnelli> So whatever comes out of the design process,... implementing it will be a challenge.
< sipa>
luke-jr: i'd say leave the UI decisions up to those working on it
< yanmaani>
well it is a bit rude to have the designers have their meetings in Slack and Zoom and whatnot
< wumpus>
when it has existed for a while we can at some point maybe look at QML for desktop, but I don't want to make that decision now, at all
< yanmaani>
and then present it, take it or leave it, with some amount of pressure, to the devs
< wumpus>
also, just build whatever you want to build and think is useful, I'm kind of tired of this discussion
< jeremyrubin>
When someone is doing work you aren't paying for you really can't demand it be on your terms
< instagibbs>
yanmaani, I didn't get this at all from the comments
< yanmaani>
it seems like it would make an atmosphere with a bit of bad communication
< luke-jr>
sipa: I work on UI
< yanmaani>
it seems like it would be better if everyone used the same platform
< luke-jr>
sipa: I also use UI
< jonasschnelli>
we don't have the data points for a decition. Someone need to come up with a live running example
< sipa>
luke-jr: yes, i don't mean to say that excludes you!
< sipa>
luke-jr: but i don't think it's something to work out here
< moneyball>
yanmaani: I think you misinterpret. I explicitly said above and in my GitHub comment that I agree with luke-jr, we shouldn't require Core developers to go elsewhere for formal discussion.
< wumpus>
native styling means nothing on mobile platforms anywy, it's fine to start without that
< yanmaani>
native styling, maybe. It's still notorious for being very sluggish, but that might just be a stereotype
< luke-jr>
wumpus: Android doesn't have native widgets? Pretty sure it does
< jonasschnelli>
as for moneyball: I think it is important to tell the designers that the _implementation_ of it will raise tons of questions. Just that they are aware that this project is different to the corporate world.
< yanmaani>
wumpus: Do app GUIs have much in common with desktop GUIs?
< moneyball>
However, there is nothing preventing people from using other mediums to communicate with each other. We shouldn't prevent designers from using, say Figma.
< wumpus>
luke-jr: yes but no one uses them
< yanmaani>
They're all profoundly different platforms
< luke-jr>
wumpus: most apps do in my experience
< yanmaani>
moneyball: Right, but then the designers will be discussing without talking to the core devs
< luke-jr>
wumpus: I think the only exception I know of is Pokemon GO
< wumpus>
in any case, qt widgets doesn't really work on android ...
< luke-jr>
⁇
< wumpus>
qml does
< yanmaani>
I mean, my worry is that you might end up with a website that looks "designed by designers" (see: angular/react monstrosities) but is horribly slow
< yanmaani>
rather than a nice HTML site with a small amount of CSS
< jonasschnelli>
yanmaani: we all share that worry
< moneyball>
yanmaani: There has been effort put forth to have Core devs and designers talking to each other. It is already happening. That said, I'm sure we can improve even more so.
< yanmaani>
uh I mean app
< yanmaani>
not website
< yanmaani>
uh I mean program, not app
< luke-jr>
maybe designers should make image files and coders do the implementation?
< wumpus>
QML is definitely not 'horribly slow'
< jonasschnelli>
the opposite
< wumpus>
it's very well optimized for animations and such
< luke-jr>
The following list summarizes what you can do with Qt for Android:
< instagibbs>
It's a lost cause to get everyone on IRC, ship sailed a long time ago. Provided typical Github workflow is followed, there's no issue
< luke-jr>
Run Widget-based and QML applications on a device or an emulator.
< luke-jr>
wumpus: ^
< yanmaani>
That seems like a reasonable idea. It would probably make more sense for designers to try and do higher-level stuff
< yanmaani>
things like "is this workflow broken", "does it make sense to order the tabs in this way"
< wumpus>
it's mainly used in kiosks and inflight entertainment and industrial devices etc
< wumpus>
usually some ARM core
< yanmaani>
wumpus: Yeah but compare Monero's GUI to Electrum or whatever
< hebasto>
QML supports hardware acceleration
< * luke-jr>
would like to see what Bitcoin Core looks like on Android today
< luke-jr>
GUI*
< yanmaani>
It's still extremely big and bloated
< jeremyrubin>
if you get the designers on IRC, they will leave core, and then work on a more pretty IRC client
< sipa>
jeremyrubin: hahaha
< wumpus>
native UI is also 'big and bloated'
< luke-jr>
hebasto: so does widgets…
< jeremyrubin>
so let's keep them focused on the task at hand
< instagibbs>
wait... that sounds great jeremyrubin
< luke-jr>
jeremyrubin: lol
< wumpus>
did you look at windowing toolkits recently
< sipa>
irc is supposed to be ugly! *plays with beard*
< instagibbs>
everyone should tmux into their IRC machine or log off
< sipa>
instagibbs: screen, ffs
< hebasto>
luke-jr: sure?
< sdaftuar>
instagibbs: i think we call it slack?
< moneyball>
yanmaani: it is unrealistic to have everyone use the same platform. designers use tools like figma. can you imagine if designers demanded developers to use figma instead of git and whatever your favorite editor is?
< luke-jr>
hebasto: yes, it's annoying tbh
< wumpus>
in any case, if the designers don't come up with something better then we can always say no, but I think rejecting any kind of improvement in advance is bad
< sipa>
wumpus: +1
< jeremyrubin>
moneyball: designers should use DCC whiteboard only
< moneyball>
at minimum GitHub will be the common communication platform
< luke-jr>
hebasto: simple GUIs shouldn't need hw acceleration
< jonasschnelli>
wumpus: +1
< wumpus>
this is how you get stuck
< yanmaani>
moneyball: Sure, but then you end up in a situation where there's almost no communication
< sdaftuar>
it seems presumptuous to tell other volunteers on this project how to work and collaborate with others
< hebasto>
luke-jr: agree
< jeremyrubin>
sdaftuar: +1
< yanmaani>
they just lock themselves in a room and present a design
< yanmaani>
Compare bitcoin.org anno 2011 and today
< wumpus>
yanmaani: please...
< luke-jr>
hebasto: by default, Qt Widgets uses OpenGL
< moneyball>
yanmaani: this is not the intention. i am genuinely reaching out here to find ways to avoid your concern
< wumpus>
meeting time is over
< jeremyrubin>
(btw for anyone connecting over Tor, please do not accept DCC chats -- easy way to dox yourself)
< sdaftuar>
moneyball: thanks for sharing this!
< wumpus>
moneyball: yes, thanks for working on this
< jonatack>
+1
< jonasschnelli>
moneyball: thanks!
< yanmaani>
moneyball: Well, you would want some sort of neutral ground. Like a phpBB forum, or maybe github is good enough.
< jeremyrubin>
excited to see what comes out!
< yanmaani>
And slack or keybase or whatever bridged to IRC
< instagibbs>
achow101, sorry, wife's company only does contracts north of $20k. Can you 1000x your offer?
< sipa>
yanmaani: "neutral ground"? is this a war?
< sipa>
yes, IRC bridging may be useful
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Sep 3 20:02:41 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< instagibbs>
yanmaani, as I noted, I think the usual github review flows should be followed. There are a number of IRC channels now for various sub-topics(build systems f.e.) but that doesn't allow sidestep of PR lifecycle
< instagibbs>
so where someone congregates to brainstorm, iterate isn't quite as important
< yanmaani>
I think it's basically a matter of how 'young' the ideas are before being brought up publically to discussion.
< yanmaani>
Too young and you'll be laughed at because it was just idle suggestions. Too old and they'll be solidified and hard to nudge right.
< instagibbs>
that's up to the subgroups to navigate imo
< sipa>
yanmaani: yep
< achow101>
I setup ##bitcoin-core-survey for us to argue about how to do this survey
< jeremyrubin>
To be fair, this conversation would be *VERY* different if we had a world-class GUI. I think the reality is that while we're good in terms of stability (I think core gui doesn't crash often?) core gui isn't fantastic. Some people are graciously offering to help, and we should encourage them to experiment rather than shackling them to "change it but make it identical to what it is now".
< jeremyrubin>
(I accept some people might feel differently about GUI quality)
< yanmaani>
I think that there's non-contentious stuff that could be done
< yanmaani>
things like "does the big log thing to the right on the main screen really need to be there"
< jeremyrubin>
non-contentious == incremental
< yanmaani>
where a qualified expert designer can offer lots of insightful advice and is sorely needed
< yanmaani>
and contentious stuff, like "let's switch to QML"
< yanmaani>
No, you can have complete overhauls where you completely change the tab structure
< instagibbs>
I'd be surprised if it ended up wholly replacing the GUI any time soon
< instagibbs>
whatever it was
< yanmaani>
Like imagine if they just straight up copied Electrum's layout
< yanmaani>
but kept the Qt, implementation, etc
< yanmaani>
I think it would be more productive to ask questions like "what is the best layout" than "what is the best GUI framework"
< jonatack>
Getting designers to use github/gitlab/etc is already asking them to use tools they don't normally use from what I saw on teams at corporates and startups. IRC, fuggetaboutit. Will check out the design channel to meet them halfway.
< jeremyrubin>
yanmaani: I think it's ignorant of existing developers struggling with aspects of qt widgets
< jeremyrubin>
so it's not a problem that's made up just to make new designers happy to use trendy new framework
< jonatack>
*design slack channel
< wumpus>
QML is not a 'trendy new framework' anyway
< yanmaani>
I mean, the basic problem is that you can see Monero using QML
< wumpus>
it has existed virtually as long as bitcoin has
< yanmaani>
and it's not very good
< jeremyrubin>
That's not a problem
< jeremyrubin>
that's like saying
< wumpus>
then we should not copy monery, easy as that
< jeremyrubin>
the problem is craigslist.com uses HTML
< jeremyrubin>
so it's not good for websites
< wumpus>
just one example of a bad GUI using QML doesn't invalidate the framework
< jeremyrubin>
(I like craigslist fwiw)
< yanmaani>
If there's a persistent pattern of projects using `X` tending to end up like dumpster fires, that's not a good pattern.
< hebasto>
jonatack: it would be nice if you find opportunity to join calls
< yanmaani>
React/Angular/jQuery have bad reputations
< wumpus>
QML is not those
< jonatack>
hebasto: are they audio or video?
< hebasto>
video
< wumpus>
also even those are used for some well-designed GUIs
< instagibbs>
there are many people who don't give a fig if something is "native" looking fwiw. That's a tiny part of UX
< wumpus>
e.g. jquery is simply a javascript utiltiy framework, it doesnt impose any specific design
< wumpus>
instagibbs: only old people care about that :)
< yanmaani>
it's also very big and bloated, and sites using it tend to have atrocious performance
< jeremyrubin>
+1; there's also an argument for cross platform consistency being good
< yanmaani>
It's not bad per se for them to be non-native, but it usually correlates strongly to a whole host of pathologies
< wumpus>
yes, they are big and bloated, qml is not though
< jeremyrubin>
yanmaani: you're just to vague and hand wavey here
< wumpus>
yes
< jeremyrubin>
if there's a concrete issue with QML, bring it up
< wumpus>
this isn't going anywhere, you're just complaining for the sake of complaining here
< yanmaani>
Fair point. It usually correlates strongly to GUIs that are sluggish and overly animated.
< jeremyrubin>
but "I don't like how other people use it" isn't the kind of reason that will get you traction here
< jonatack>
hebasto: thanks. at least it's jitsi, not zoom. might try joining in (with my camera off ;)
< wumpus>
if people want to do a QML GUI for bitcoin core, let them
< yanmaani>
With bad latency, and so on. I think that switching the UI framework and redesigning the design are two orthogonal issues
< hebasto>
jonatack: this morning my camera was off too
< yanmaani>
The designers are presumably going to have good layout suggestions like "change the receive tab", not just "bitcoin-qt with a different theme". So I think that it is still going to be useful.
< wumpus>
UI designers tend to not know how to work with qt widgets, so that is off the table
< instagibbs>
hebasto, remind me in a month or so, I'll probably start listening in on calls too
< wumpus>
the idea is to get new people involved here\
< hebasto>
yup
< jeremyrubin>
I think also w.r.t. layout there's going to be other things that come up that are not layout.
< yanmaani>
wumpus: The design work doesn't need any such. You can just draw mockups or whatever and have someone else implement it. You could (presumably) do your mockups in QML just fine, that's true
< wumpus>
no one really knows how to work with qt widgets
< wumpus>
so who is going to do the work then ?
< yanmaani>
Aren't there ordinary developers working on the GUI?
< sipa>
for historic context: the current qt widget ui was originally written by wumpus
< wumpus>
'having someone else implement it' doesn't help if no one has the expertise, we're trying to get new people involved
< wumpus>
yes
< instagibbs>
did I mention how much I love the QT
< instagibbs>
I can fudge with stuff in QT, but anything serious I offload to someone else
< sipa>
instagibbs: i think that's how most people feel
< wumpus>
I started very enthousiastically back in the day and just burned out on it, my idea back then was also to get new people involved, but I had overestimated the amount of people in open source that really know how to use (and are good with) qt widgets GUIs
< yanmaani>
if you wanted to get really grandiose, you'd try and coordinate with Electrum folks
< sipa>
wumpus: i'd say it was a serious improvement over a pre-release version of wxwidgets :p
< yanmaani>
on how to design (but not build) the best GUI
< hebasto>
jonatack: correct
< wumpus>
sipa: it was! it just got more or less stuck in time
< jonatack>
hebasto: ok, noting in calendar
< luke-jr>
wumpus: Qt Widgets isn't hard..
< wumpus>
fwiw I think the GUI is mostly OK, I do use it myself
< yanmaani>
agreed
< wumpus>
luke-jr: still, there are very few people who want to use it, saying "it is not hard" is easy to say
< luke-jr>
I'm mostly just happy with the current GUI :P
< yanmaani>
it has some warts though, like the receive tab and the payment request system
< luke-jr>
yanmaani: ?
< jeremyrubin>
It's hard to self-evaluate software you've used for a long time. I don't agree with a lot of current design methodology, but there are scientifically rigorous design methodologies e.g. used in the DoD
< yanmaani>
I've never seen anyone in the wild use the URI stuff, just "send bitcoin to address X"
< wumpus>
WELL improve it then
< wumpus>
it's open source
< wumpus>
scratch your own itch
< wumpus>
instead of complaining complaining complaining
< yanmaani>
so it would make more sense to do it like in Electrum - you have a list of addresses, and you can copy them, and see if they're clean.
< wumpus>
I'm tired of this, just figure it out
< luke-jr>
yanmaani: that's what we had before. why would you want that⁇
< yanmaani>
wumpus: the reason I am asking is because I would like to know if others have the same issue
< jeremyrubin>
current design methodology ==> general designers, not specific to core
< yanmaani>
and, clearly they don't
< luke-jr>
the receive tab works great IMO
< yanmaani>
Well, there's one click to get an address. It would be nice if you got one just by opening the tab.
< wumpus>
I'm looking forward to what people come up with QML in any case
< yanmaani>
But if there are good reasons things are as they are, that's obviously a good reason to keep them like they are
< luke-jr>
yanmaani: how will it guess the label you want?
< phantomcircuit>
jeremyrubin, transaction has too long of a mempool chain in a pr changing something about the mempool seems likely related
< jeremyrubin>
I'm fairly certain it's unrelated
< jeremyrubin>
the evidence being that all other tests pass & the change does not impact any "logic", just data structures.
< jeremyrubin>
This type of error can come up in a test if we're not careful with how we generate a txn/children and if we get everything mined at the correct time
< achow101>
it's the 19853 problem. the failures listed there are the same
< jeremyrubin>
even better evidence :)
< jonatack>
yep, saw the same travis ci failure in a couple of PRs reviewed today
< * luke-jr>
wonders if it would be bad to alias make='make -j32'
< sipa>
luke-jr: i don't know what the optimal number of build threads is, but for test_runner it's huge (a large multiple of core count for me)
< luke-jr>
sipa: well, I mean the alias itself - will I regret not having -j1 as a default?
< aj>
depends how much memory you have, c++ takes up a fair chunk
< luke-jr>
aj: yeah, -j64 wasn't pretty lol
< phantomcircuit>
sipa, i've always done -j for the test_runner, on systems with swap it's faster than any limit
< yanmaani>
If you want it to go faster why not use meson or something?
< sipa>
how does a different build system help with that?
< yanmaani>
I've always heard meson was faster
< yanmaani>
But it might just be folklore
< phantomcircuit>
yanmaani, the autotools stuff is slow, but that's because it's single threaded, make itself though is quite fast
< yanmaani>
I guess you're bottlenecked by the compiler here. The real big-brained move would be to have some way to track the memory size, and spawn new gcc/clang instances when the memory util goes below some level
< sipa>
yanmaani: every build system has advantages and disadvantages, but replacing one (and all infrastructure we have on top of it) with another would be an enormous effort
< sipa>
(and just adding a new one in addition is unlikely to be acceptable, as it means more maintenance work for all contributors)
< sipa>
also make is super fast, really - the autotools configuring is pretty slow, but that's not the issue here
< yanmaani>
Right, but if you'd have make with some -jAUTO switch, that would be much faster
< yanmaani>
if you're constrained by RAM, then sometimes you can run 20 instances at a time and sometimes barely one
< sipa>
one -j per GB or RAM is my rule of thumb, and not more than your number of cores
< sipa>
works well
< yanmaani>
humans are greedy, they always want more
< yanmaani>
money, fame, power, build performance, it's all the same really
< luke-jr>
sipa: I have 64 GB RAM, so doesn't work well for me :P
< luke-jr>
yanmaani: something like -l I guess
< phantomcircuit>
luke-jr, just get more ram and run everything with -j
< luke-jr>
phantomcircuit: -.-
< sipa>
luke-jr: your ram is inadequate and you should feel inadequate
< aj>
i use -j12 with 16GB and 8 cores, seems to be okay
< sipa>
(i have 32 GiB)
< yanmaani>
luke-jr: like -l but with RAM yes
< aj>
oh, i guess i'm not running a web browser on the computer i compile on, so that probably saves 5000 GB or so of ram
< yanmaani>
and with mechanisms to kill runaway processes and restart them
< achow101>
I use -j32 and I have 64 GB
< sipa>
yanmaani: that sounds very useful
< * sipa>
volunteers yanmaani to write it
< aj>
yanmaani: systemd as a build system?
< yanmaani>
an ounce of googling is worth a pound of dev time
< dongcarl>
aj: Don't give Lennart any new ideas
< luke-jr>
sipa: and you run -j32?
< luke-jr>
yanmaani: actually, SIGSTOP is useful when you hit swap
< luke-jr>
yanmaani: when/if I do catch myself losing control of RAM, I killall -STOP cc1 and slowly resume them
< yanmaani>
yep, a script to do that and you're all set