Development meeting held @ 3PM UTC in grincoin#dev channel on Keybase. Meeting lasted ~ 110 min.
Notes are truncated, and conversations sorted based on topic and not always chronological. Quotes are edited for brevity and clarity, and not always exact.
Community attendance:
- antanst
- antiochp
- bladedoyle
- dburkett
- funkyswing
- jaspervdm
- joltz
- kurt2
- lehnberg
- phyro
- quentinlesceller
- rsgags
- tromp
- xiaojay
- yeastplume
(apologies if I missed someone - submit a PR or contact @lehnberg to add)
No retrospective in this meeting.
Proposed agenda reviewed, and accepted, with point 4 and 5 trading place on the agenda, and testing and packaging points being tabled to next meeting.
- yeastplume: No longer in the realm of science fiction, thanks to @jaspervdm
- jaspervdm: \o/ just saw it looks kind of shit on lower screen resolutions, but at least its there.
- quentinlesceller: Very nice @jaspervdm. Can you quickly how it works? looking at logs?
- jaspervdm: Using the webhook feature, storing all incoming tx, then doing analysis on each block.
- yeastplume: Yes, looks really good, well done
- quentinlesceller: Nice. Next step blockchain clustering :p
- lehnberg: Very nice work @jaspervdm, haven't had a chance to look at it but will do so and get back to you with any feedback.
- jaspervdm: Thx all
- lehnberg: No progress: While Jasper shines, I've not been able to find time to do that.
- quentinlesceller: 🔔
-
jaspervdm: I think managing stable/beta branch requires upkeep from us. But in principle can be automated, we can have a look at how rust does it for example.
-
antiochp: We looked into stable tag vs stable branch and I think at the end of the day it's not adding much value given the added complexity.
- yeastplume: I would kind of tend to agree
-
antiochp: We would need to exclude some tags/branched from the automated build process. And keep them updated ourselves. I think having
masterand then various released tags is good enough for now + release branches. -
jaspervdm: Its nice to be able to tell
git checkout stableto users, but realistically anyone needing that command should juts use the binaries- dburkett: I tend to disagree. I think should be encouraged to build locally. Building locally is safer than saying "hey, here's some binaries. there are no backdoors to steal your money, just trust me".
- jaspervdm: Hm, so how do you do it for grin++? Do you have stable/beta branches.
- dburkett: Lol, the wild west, basically. I just use master for everything, and make sure it's stable. Do as I say, not as I do 😆.
- jaspervdm: Heh ok. Even building from source is a somewhat trusted process given that the rust compiler is a bootstrapping compiler, but I get what you're saying.
- dburkett: Sure, but if someone can release a malicious rust compiler that somehow steals your grins, then nothing's safe.
-
jaspervdm: Ok, lets think a bit more about it. I kind of want to have a look how easy it would be to automate
-
dburkett: I wasn't making an argument about stable vs master, btw. I just was saying ideally users should be able to build locally. But the world's not ideal. Didn't mean to derail.
- lehnberg: All good, think it's a good point
-
yeastplume: Okay, so... what do we think we want to get in to 4.0.0 a.k.a hf3. Pow changes go without saying, nkotb kernels would probably be the most pervasive.
-
antiochp: Relative (aka recently seen) kernel locks is still on the cards
- dburkett: You don't think it's rushing to squeeze relative kernels?
-
tromp: Parallel ibd?!
- 👍: lehnberg
- dburkett: Parallel ibd can be done anytime. doesn't necessarily have to be on a hf
- jaspervdm: It requires new p2p messages right? would be easiest to activate during hf, but not needed
- dburkett: Yeah, but we have a versioning mechanism we can use.
- tromp: Pibd will bring noticeable usability improvements
- dburkett: Yeah, I have a started rfc on it, and all the messages defined on paper. I need to type it out and submit a pr.
-
quentinlesceller: Wondering also if when we should deprecate node api v1.
- 👍: lehnberg
-
tromp: Relative kernels is important for long term development, not urgent
- yeastplume: Yes, but we're a year and a half in and have been talking about it since before launch, would be nice to have some progress on that front.
- antiochp: Agreed not urgent but it would be good to get the consensus changes in there via one of the scheduled hfs.
- tromp: Relative kernels definitely have to go in by hf3 or hf4
- 👍: lehnberg
-
lehnberg: At the risk of sounding like a broken record, slate and tx building process. this wouldn't have notable usability improvements, but might make some tx building methods easier, and might reduce leakage of data.
I'm stressing about it because we have two hard forks left to get it right without creating incompatibilities across wallets.
-
antiochp: (that implies some level of urgency)
-
yeastplume: @lehnberg are you talking about this issue? mimblewimble/grin-wallet#317
-
lehnberg: Yeah, in part. but I wonder what else there is we could look to improve there.
-
yeastplume: Yes I think it's worth looking into the 'slate lite', e.g. reduce what get passed around to the minimum info needed.
-
dburkett: For hf4 (v5.0.0) I was going to submit an RFC for non-interactive txs. That will remove the need to deal with slates, if we want to go that route.
- jaspervdm: Any eta on that RFC? I think we would need a lot of time to discuss.
- lehnberg: Yeah, this is sth I've been thinking about as well, how this potentially eliminates a swathe of challenges. I urge you to try to get that RFC out in the wild as soon as possible. Even if hf4 is almost a year away, it will require a lot of thinking and scrutiny.
- dburkett: I can submit it this week if needed, but I wanted to gauge interest before going through the effort. Latest design is in #tx-building, so if that seems like something worth pursuing, I can get an rfc written relatively quickly. Here's the litecoin version: https://github.com/davidburkett/lips/blob/master/lip-0004.mediawiki. I've been trying to get as many people as I can to review it. Nobody has pointed out any problems yet, but it's still early.
- lehnberg: Yeah, unfortunately that's far from there not being any problems, or there being consensus around the proposal.
- yeastplume: Same here, sorry. I'd definitely say it's worth coalescing into a preliminary draft RFC, it doesn't need to be massively detailed, but just get all the info together in once place as a draft pr for everyone to consider?
- dburkett: Sure, it's going to look a lot like that lip :)
- yeastplume: Sure but at least we'll have a central point for the grin-specific discussion
- 👍: dburkett, quentinlesceller, lehnberg
- dburkett: Have reached out to a few respected cryptographers for review as well. waiting to hear back.
- 👍: kurt2, quentinlesceller, rsgags
-
yeastplume: So, seems this far we have 'relative kernels (possibiliy), 'slate lite' and pibd.. Is there anything else? And pow changes.
-
tromp: I alrd have a design in mind for next cuckaroo29. Just needs to be coded up
- 👍: quentinlesceller
-
quentinlesceller: Deprecate node api v1?
- yeastplume: @quentinlesceller sure, was just trying to get the consensus or completely breaking changes in first.
- quentinlesceller: I'm torn about this since having a rest endpoint is still very nice for stuff like status. There is no urgency to remove it. I'd encourage exchanges and devs to work with v2 (maybe add deprecate message during build?) and revisit after hf3.
-
lehnberg: Deprecate http? Or still too early
- yeastplume: If we deprecate http, it's going to make a lot of developers at exchanges very unhappy
- lehnberg: So a good time to do now that there are still relatively few exchanges?
- yeastplume: And the primary method is to become Tor? Which is just a layer on http anyhow. In all cases you still need an http listener of some description running
- lehnberg: So deprecating would be to announce that from 5.0.0 and onwards, it will be removed. (as part of 4.0.0). I don't think there's any other option to go about it. And if we want to get rid of http (for end users at least), then that's the time.
- 👍: dburkett
- yeastplume: We can't remove it though.. the only thing we could really do is remove the option of exposing an http listener to external addresses
- 👍: funkyswing
- dburkett: Right, same thing we do with owner listener. Just listen on localhost.
- lehnberg: Unfortunately I don't have an amazing strategy for the alternative (yet). Just saying that if we're doing this right, we need to announce well in advance and be very clear.
-
yeastplume: Tor becomes the default?
- 👍: joltz, funkyswing
- xiaojay: I don't think it's a good idea to make tor as default, because in mainland China, Tor is totally blocked. And it will make most end user can not send/withdraw grin to/from exchanges.
- 👍: funkyswing
- yeastplume: @xiaojay that's another concern
- joltz: We could offer a pluggable transports option at some point. https://2019.www.torproject.org/docs/pluggable-transports.html.en
- dburkett: There's also that
- yeastplume: At the moment, tor is the default if tor is installed and works and you run a listener. Http is very much the fallback.
- dburkett: Turkey also blocks Tor. VPNs solve that. Not a big deal for Turkey since it's not illegal. For china it probably is.
- quentinlesceller: yeah the problem by using tor by default, while it looks ideal, it would hurt the usability.
- dburkett: I disagree. Http has been horribly unusable. The only way most people are using http now is because jay and I each run nice, easy-to-use mitm services. If either of us goes rogue, we could steal a lot of grins.
- yeastplume: Tor's nat punching is very favorable for usability.
- xiaojay: Yes, maybe file-exchange should work
- dburkett: Good point. we do still have file
- yeastplume: In any case, can we put this down as a question mark for 4.0.0 and we can have a larger discussion/think about this?
- dburkett: I'll bet if we remove http support, chinese exchanges like kucoin would finally implement file support
- 👍: funkyswing
- xiaojay: Yes, I think so
- joltz: If we do force Tor as default I think we want a good option to ensure folks in china can still easily connect, whether we run our own obs4 somehow etc may still be open.
- 👍: dburkett
- lehnberg: @joltz would you like to research our options there? Could be useful in any case
- joltz: Yep I'm on it 👍
- 🚀: lehnberg, yeastplume, quentinlesceller
- yeastplume: And we can open a separate discussion issue for it I think, away from the main list of 4.0.0 issues.
-
yeastplume: So, I think we have a preliminary list of points to address in 4.0.0. We get them all into an issue, start discussing there and meet back on it at the next dev meeting?
- 👍: jaspervdm, xiaojay, lehnberg, joltz, quentinlesceller
-
lehnberg: Will update #248 based on the initial ideas penciled here
- 👍: quentinlesceller, xiaojay
- yeastplume: @lehnberg great, thanks!
-
yeastplume: Are we really ready to give up on the scheduled hard forks?
- tromp: I am. we should not rule out future hf, but they can be purely on an as-sorely-needed basis
- lehnberg: How do you envisage that working in practice @tromp?
- tromp: As consensus builds that some consensus breaking new feature is highly desirable, we figure out a good time for doing a hf.
- lehnberg: But how do you achieve consensus around that? Seems like this is where most projects will stumble.
- jaspervdm: Good question
-
jaspervdm: Ok there's many sub points on that, but here's my opinion in short: I am okay with adding 1 additional hard fork 1 year after the last. I am also in favor of making the code more soft fork friendly. however I think miner signaling is a bad idea, judging from history
- 👍: quentinlesceller, lehnberg
- quentinlesceller: Agree with @jaspervdm
- dburkett: Miner signaling does suck, but how should future forks be agreed upon?
-
yeastplume: I would like to dissect a bit. I'm of the opinion that we should allow for hardforks, just not on the same frequency. I'd like to hear more about why scheduled hard forks are a bad idea?
- lehnberg: It's a centralizing force on the network
- yeastplume: To me, it's like saying 'windows 95 is good enough, so let's make it extremely awkward on ourselves to roll out any updates to it'
-
lehnberg: The "problem" with adding more hard forks after the "only 4", is that we kind of open pandora's box. will we ever say "you know what, now we're good and there will never be any more scheduled hard forks"?
- yeastplume: No, that will never happen and never should happen. There will always be improvements. But all of the benefit of everyone knowing dates in advance, and having communication on upcoming forks and dates, and forcing upgrades, I think is huge.
-
lehnberg: Maybe it's better to not put any scheduled ones in beyond those that we're in pre-mainnet and then just 'deal with it'
-
tromp: We'll still do plenty updates. Just be conservative about consensus breaking ones. Trying to make grin immutable by default, like bitcoin. But not as hf averse as bitcoin. Segwit would've been much cleaner as a hf. And grin is big on simplicity.
-
antiochp: I agree that "immutable by default" is a good principle
- 👍: funkyswing
- lehnberg: This
-
antiochp: > segwit would've been much cleaner as a hf
but probably impossible to actually pull off
- lehnberg: And sadly also this. :/
-
lehnberg: If we always have scheduled hard forks in the code, anything can happen if the core team wants it. Which makes it super super centralized.
-
joltz: Hf averseness can be good. It is nice to know you can hibernate for 5 years and wake up still able to spend your btc.
- yeastplume: If your keys are intact.. This should always be possible, though you may need to update your wallet software and rescan. And if we become immutable, someone competent will come along with a fork will change that.
- tromp: It's crucial for wanting grin in 100 years to resemble grin today. What it comes down to is that for a decentralized coin, it's good to have a little friction to hardforks.
-
jaspervdm: My fear for not coding in an extra hf would be that impossibility of any hf.
-
phyro: I agree with the immutability perspective, but what happens if there is an easy way to achieve unlinkability but we only start researching this after the "last" hf? It would mean we want to do as much research in the beginning to make such scenarios sort of less likely to occur.
-
lehnberg: I definitely think there's a logic for us saying sth like:
"Grin is very young in blockchain years. We're an open source project, and things take their time. There's no way we will be able to get all the consensus-breaking stuff into these four hard forks. We need more scheduled hard forks. Because we're still in open heart surgery on the patient. But. we are aiming towards a future of no scheduled hard forks."
But the "we're in dev mode" excuse can only last for x years, at some point we'll have to be considered mature.
- joltz: Right but if there are tons of forks how do I know what to actually download?
-
kurt2: I like the idea of opening a window to hf every four years. It is a good compromise between being hard to change (which definitely has value, imo) and the need to adapt with new tech when you are a coin like grin. Also it is more predictable than choosing when the need arise, which has it's own value too in term of organisation, philosophy and preparation (athletes usually prepare for bigger event during years on a predetermined schedule). I would see many advantages in that schedule. But not really against visions too (every 1 year for example).
-
tromp: I'm not opposed to hfs, just opposed to making them too easy, as in having them prescheduled.
- 👍: dburkett, phyro
- lehnberg: But how do you reasonably make them happen otherwise, unless there's a huge reason for them?
- dburkett: The reason hfs were pre-scheduled was because we made a promise to be asic-resistant for 2 years.
- lehnberg: Not true, they were scheduled in before this became a discussion point.
-
yeastplume: I tend to prefer agile and nimble development, and would hate for us to put the block on that artifically early.
-
tromp: Specifically, I'd like to take out the built in expiry dates in grin v5.
-
lehnberg: If we're doing the type of improvements we've been targeting for major releases so far, they would not have been hard forked in.
-
joltz: I don't see a significant difference in 2 years of planned hfs vs 5 years of planned hfs looking at a long time horizon. But I do see a significance in leaving the possibility of hardfork open ended to be decided by core at some future date. Leaving optional unscheduled hardforks by core on the table as reasonable options for upgrades in the future.
- jaspervdm: Not sure if giving "core" such a long-term power is a good idea
- yeastplume: What is the alternative? I'm fairly opposed to miner signalling.
-
tromp: There is one not-yet-mentioned downside to not having scheduled hfs though. They're good excuses for slipping in critical vulnerability fixes
- 😂: dburkett
- dburkett: We've only done that once! :)
- lehnberg: Something tells me it won't be the last... 🌝
-
jaspervdm: Yeah me too. just worried about leaving it open ended. Im ok with it for the shorter term
-
yeastplume: If there were something like 'stake signalling,' that might be more fair. I'm sure there is, I just haven't read up on it. (and it would require a working proof-of-stake).
-
yeastplume: It's like giving banks total power over monetary policy... hmmm. There's already a system that works like that (and it would require a working proof-of-stake).
- joltz: And steem is a nice current example of how that can be abused by exchanges.
- yeastplume: @joltz indeed, of course.
-
lehnberg: If we include one scheduled hard fork, it gives core the power to include any scheduled hard forks in the future (they just add those into that one). But it would become very contentious. But so is there a difference between one scheduled and say five, once a year? I guess if we agree on five now, the topic dies for five years. If we agree on one, then every year we have this debate.
- joltz: I think the difference is whether the per year is left open indefinitely?
- yeastplume: I think it's too early in development to throw out scheduled fork changes
-
dburkett: Let's ask this: is there something we want to get in a hf that we can't finish by 5.0.0?
- lehnberg: I'd like to posit that we're in the sorry state of not even knowing what we don't yet know here
- jaspervdm: Heh was about to type that.
- dburkett: Right, but how will a new scheduled hardfork help. will we know anymore 1 year from now?
- lehnberg: That's a fair point, in a way it just kicks the can down the road.
-
tromp: It's best to stick to the original storyline. that we would only do 4 scheduled hfs
- yeastplume: Linear falloff hf schedule?
-
antiochp: I'm with @tromp on this - future hfs should need to build enough consensus across the community
- lehnberg: How would we have handled the last cve this way?
-
lehnberg: There's no way we'd be able to plan for a good enough state in order for 5.0.0 to be the last scheduled hard fork. Happy to be proven wrong about it, I just don't see it, and wanted to kind of put it on the table
-
lehnberg: But at least it gives us a chance of getting better at this in the meanwhile.
-
joltz: At a certain point it has to be left up to the community otherwise we are just running a pseudo centralized network
- lehnberg: Agreed
- jaspervdm: Agreed, thats why I was advocating for adding 1 extra. Then we could review at that point if we are at that point yet.
- yeastplume: Absolutely. I just think it's too early. we have virtually none of the 'future tech' in at the moment.
- dburkett: What 'future tech'?
- yeastplume: We don't even have relative locks in at the moment, never mind the stuff that could build on it
-
lehnberg: I'd almost be inclined to go the other way: put five years of hard forks in. And if we get to a point where we don't need it, we take it out.
- joltz: The problem I think is that it will always be too early
- 👍: dburkett
- antiochp: That's a lot of "we" and a lot of subjective "need it" there
- lehnberg: I don't disagree. But the whole thing is subjective - Why four and not eight scheduled hard forks?
- joltz: I don't think there is a significance here besides what was already committed to.
- dburkett: Because our bdfl said so. Relative locks should be in by 5.0.0. everything that builds on it shouldn't require a hardfork.
- joltz: The problem I think is that it will always be too early
-
antiochp: Yeah - we agreed on a rough timeline early on, there needs to be a real solid reason to change that now I think
- lehnberg: I can buy that argument. So what do we do between now and jan 15 2021?
-
yeastplume: If we're not going to do more hardforks, we need to be very clear on what the consensus mechanism is for introducing them
- 👍: dburkett, joltz, lehnberg, bladedoyle
- dburkett: Yea, that's a tough one
-
tromp: It's likely that we will have a non-pre-scheduled hf next year. It will instead be scheduled based on new features that were discussed with the community and that most agreed merit a hf.
- 👍: joltz
- dburkett: It's not like we aren't creating new releases. We just won't hardfork. Most 'future tech' can be done with a soft-fork at most.
- yeastplume: Fair, we'll just be losing the ability to keep everyone on the same page
- dburkett: Yes. that's why we're having this conversation now. We need to build upgrade-ability into our code.
-
lehnberg: But who's "the community" here? the people on keybase? Are they the ones running the nodes? I fear that we'll get to a point where "the community" agrees, but the network doesn't fork
- joltz: I'd argue the community doesn't really agree then.
- tromp: The comunity is people joining the discussion on the grin forum, and keybase channels, and dev/gov meetings
- jaspervdm: How about exchanges, mining pools etc? if they refuse to join the fork, you're making it orders of magnitude harder for yourself.
- tromp: The consensus mechanism for new features is rfcs. We need to get pool and exchange represented.
- lehnberg: I don't think they care enough
-
yeastplume: One thing that's occurring, grin isn't as big as we think it is either.. we do tend to be in an echo chamber. we're a long way off pools and exchanges having an opinion on grin other than rolling their eyes and assigning developers to it whenever we introduce a new version.
- 🙂: joltz
- jaspervdm: Right, which makes it more likely that they won't perform the effort to fork if its not forced on them.
- yeastplume: Do a lot of these arguments apply to where we'd like grin to be one day as opposed to where it actually is? This leads me back to 'far too early' thinking.
-
bladedoyle: How can a discussion lead to known consensus? how do we know those in the discussion are not just puppets?
- dburkett: Kyc 😜
- joltz: You can't, that's why I said that if the network doesn't fork the community doesn't actually agree
- bladedoyle: So reaching consensus means convincing the dev team. How is that different from the dev team just deciding to have a hf?
- yeastplume: @bladedoyle I think the point is that if we cut off all hfs, we'll need a better mechanism than that. Convicing the dev team to add new features just means getting an rfc accepted by the community (then anyone can develop it). That is, new features that don't need a fork.
-
lehnberg: If we don't add any scheduled hard forks, how do we do unscheduled hard forks, and (somewhat separately) how do we do soft forks?
-
jaspervdm: If the dev team decides to do a hf that is not pre-scheduled, users can just not follow the updates. So I do think its fundamentally different
- tromp: Maybe we can avoid soft forks alltogether. If consensus layer is worth changing, then it's worth changing by hf.
- bladedoyle: Soft forks seem very messy and arguably less democratic than hard forks.
- dburkett: You can get quicker deployment with a soft-fork though. And then clean it up later during a hardfork (assuming we aren't bitcoin's level of hf-averse).
- jaspervdm: You would have to keep the ugly stuff in though, to be able to validate the intermediary blocks.
-
bladedoyle: Honestly I think we don’t need to worry so much about it yet. “the community” is small and generally agrees.
-
dburkett: A soft fork is a consensus change
-
tromp: Grin has no reservoir of nop instructions waiting to be softforked
- dburkett: Good point. I proposed a way of allowing future kernel types.
-
dburkett: Also, the non-interactive txs proposal is almost soft-forkable as-is. I'll bet I could even come up with a way to do it full-sf
-
tromp: Grin has kernel features, but they should not need nearly as much new functionality as bitcoin script
-
jaspervdm: That would not allow us to change signature scheme for example, right? Basically allowing any kernel type as long as signature is correct
-
dburkett: It could allow you to add an additional signature scheme, but not modify the existing one. But there's a lot you can do with that.
- jaspervdm: Yeah true, was just trying to understand
- tromp: I'd rather introduce new kernel features by hf than softfork.
-
bladedoyle: Grin is still very centralized anyway. I think a few more scheduled hf won’t hurt as much as it would help.
-
dburkett: I could make the existing signature scheme useless, have everyone publish blinding factors, and add a new signature scheme that actually enforces consensus. Not sure you'd want to, but there's lots of weird things that could happen.
-
yeastplume: How about something like, 'if we don't come up with an acceptable consensus mechanism for introducing hfs by a certain date, we schedule another hf for one year from now, to repeat until first condition is satisfied?'
- dburkett: Well, bitcoin still hasn't figured out an acceptable consensus mechanism. Because one likely does not exist.
- joltz: Decred's model is novel
- dburkett: For sure, but is it "acceptable"? does it result in the best tech being deployed?
- joltz: It doesn't fit with our minimalist philosophy imo, but may be a viable alternative in general.
-
tromp: Ok, let me turn that around: If we don't manage to do an impromptu hf within one year after hf4, then we'll go back to putting in 2 more scheduled hfs (each one year apart).
- dburkett: Eh, I don't want to encourage impromptu hfs. I just don't want to make them impossible
- antiochp: Kind of blackmailing the exchanges and mining pools with that one
- yeastplume: That means we schedule 2 hfs in for years 4 and 5, and our first impromptu hf removes them?
- tromp: Yes. If we prove we can do hfs on as-needed basis, we shouldnt need the prescheduled ones.
- lehnberg: Doesn't that just incentivize impromptu hf1 but not impromptu hf2? What's to say the 2nd one will work just because the 1st one did?
- antiochp: Each hf schedules a subsequent one a year later, and cancels any other scheduled ones.
-
lehnberg: Just to be clear on my own (fluctuating) position:
- I don't think we should keep scheduled hfs in indefinitely, and see it as a centralization problem.
- I do think that if we don't have scheduled hard forks, it's going to be very difficult to hard fork at all.
- I do think that we are in dev mode still and will be painfully needing to introduce consensus breaking changes for a long time forward, but definitely more so early on rather than later in the future. Now how long is 'long enough'? No idea.
- yeastplume: My position fluctates within those general parameters as well. So, moving on from here, obviously we're not going to resolve this now, but we need a separate issue started to resolve this soon. And the main focus for that issue would be 'how do we intend to agree on and perform hfs after hf4'. Well, one main focus anyhow.
-
yeastplume: But in the meantime, for planning purposes we should assume the default, and plan as if hf4 is the last. is that fair?
- 👍: jaspervdm, joltz, antiochp, lehnberg
- lehnberg: Seems good to me 👍
- tromp: Yep
- quentinlesceller: 👍
-
yeastplume: I wanted a quick discussion on this point, just enough for a yeah or nay on whether it's worth discussing further. Moving all the configuration and startup, etc into a separate project altogether, making 'grin' and 'grin-wallet' library projects. Then we have a top-level project that handles the setup and environment for both and produces the grin-wallet and grin binaries as separate targets. It would also include all integration tests that use both, as well as another binary/lib that starts up servers and wallets quietly and exposes their apis for other consumers (e.g. developers of wallets).
- quentinlesceller: I think this a very good idea
- jaspervdm: Yep
- tromp: I think grin-miner can also be a libary, with the executable built in joint repo.
- quentinlesceller: Grin-miner would be a bin which would use the grin library. We could build grin-miner as well from there @tromp.
- yeastplume: Yep, we could include grin-miner too
- dburkett: That last line has me iffy
- dburkett: We have a new binary that then creates child processes?
- jaspervdm: Could be within the same process
- yeastplume: I'm thinking about a sample harness that lets developers use that project as a foundation for their gui wallets. Not so focused on the detail at the moment, but such a harness would have a lot of shared init code with the current command line init and startup.
-
joltz: I think we'd want to considering it's use for some integration testing
-
yeastplume: It might make development a tiny bit more tedious separating the library out, but I think it will help quite a lot with our testing and enable upstream development
-
bladedoyle: Having a lot of separate repos makes it harder to build from source.
- jaspervdm: End users will not be building that repo likely. It will be used as a depdenceny by (gui) wallets.
-
yeastplume: Okay, sounds good anyhow. nice thing is that the consolidated repo can be worked on independently of everything else, we'd just need to decide when to rip out the init code from wallet and server. I'll start an issue (and perhaps even a repo) anyhow, and we can discuss timing at the next meeting?
- quentinlesceller: Sounds good to me 👍
- bladedoyle: Does each binary/ lib really need its own repo tho?
- yeastplume: No, we'll have one repo that produces all 3 binaries. Grin, grin-wallet and grin-miner
- bladedoyle: 👍
No update.
No update.
None.
Meeting adjourned.