Development meeting held @ 3PM UTC in grincoin#dev channel on Keybase. Meeting lasted ~ 120 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:
- antiochp
- cekickafa
- dburkett
- dtavarez
- jaspervdm
- joltz
- lehnberg
- paouky
- phyro
- privacybydefault
- tromp
- yeastplume
(apologies if I missed someone - submit a PR or contact @lehnberg to add)
-
antiochp:
5.0.0-rc.1is released:- https://github.com/mimblewimble/grin/releases/tag/v5.0.0-rc.1.
- https://github.com/mimblewimble/grin-wallet/releases/tag/v5.0.0-rc.1.
I think everyone has been heads down making sure this went smoothly.
The proposed agenda was reviewed with "wallet command aliases" added as a point.
- lehnberg: The tokio fix seemed to have helped the exchange.
- 🚀: antiochp
- jaspervdm: Did you ask them to test the latest beta? Since we had to make another change to it.
- lehnberg: I've not asked them to test rc1 yet, let me do that now.
- jaspervdm: Oh ok, thanks.
- lehnberg: Yup. It's wallet only right?
- jaspervdm: Yes.
- lehnberg: I suppose they should run both node + wallet rc1.
- antiochp: Would not hurt but not strictly necessary.
- lehnberg: Oki done.
- joltz: Outside of the tokio fix I think the balls are in the courts of the exchanges. We have decent documentation and have been reaching out far in advance.
- lehnberg: That was the only update I had. This exchange supports slatepack (text) so if the issue gets fixed, they may be able to turn the wallet back on again.
- tromp: Only tradeogre kicked the ball out of their court?!
- joltz: Grinmint has integrated slatepack as well (though they are not an exchange).
- antiochp: I guess we actively push people toward exchanges that are known to support slatepack as/when questions come in via the forum.
- paouky: Somebody mentioned that bitforex said they'll add slatepacks soon, not sure if true though (although I suspect it is).
- lehnberg: There needs to be incentives for an exchange to do it, I think.
- antiochp: Right.
- lehnberg: Not sure current grin volume is a strong enough incentive on its own. But if enough exchanges delist, I suppose the few that do not will get more volume.
- lehnberg: At some point there will be an equilibrium. Hopefully >1.
- paouky: I'm not worried too much honestly. I think were good.
- 👍: phyro
- lehnberg: Yes, we'll see.
- antiochp: Will be interesting to watch and see how exchanges handle this over time.
- lehnberg: Shame we didn't have sth like slatepack at the point of mainnet launch, but having it at 5.0.0 is better than not having it at all.
- 💯: paouky
- phyro: I'm also not that worried. The text based flow shouldn't be too hard to do - probably much easier than it was the first integration.
4. Funding request: David Tavarez Q1 2021
-
dtavarez: I'm here to answer any question.
-
lehnberg:
jan, feb mar 2021 3 x eur 6000 28hrs/week -
phyro: Has my support. 👍
-
tromp: My question: Do you really only spend 28h / week on this? Feels like so much more.
-
dtavarez: Yes I do.
-
lehnberg: Task list:
- to keep the arm64 branch of grin++ up to date with master. - improve the tor interaction. - fix the found bugs during the beta period. - allow to initialize a transaction without requiring an Address. Add more detailed information of the transaction. - include translations to another languages. - work on improving the ui.what changed regarding my previous request?
the requested rate is greater than my previous request and the hours per week is slightly less, why? I was too optimistic with the estimation and totally underestimated the amount of work, which made me spent a huge amount of extra hours to meet the deadline. I have finished totally burned-out and I take all the responsibility. This time I want to keep a good pace during a longer period of time, because I plan to keep contributing during 2021.
-
dtavarez: Last 3 months I did a bit more than that, But I realized that is not sustainable over a long period of time. But it turned out to be work that I had anticipated.
-
tromp: Well, the last thing we want is to burn you out.
- 👍: dtavarez
-
tromp: I'm in full support.
-
dtavarez: I will try to make a better balance this time.
-
antiochp: I'm 👍 on this. Great to see the mobile impl progress.
-
jaspervdm: Yeah, 👍
-
joltz: 👍 from me, very happy to have you here @dtavarez it has been great watching the progress. I can't wait to see what comes next from you, the full node on android is amazing to see.
- 👍: privacybydefault, yeastplume
-
lehnberg: @dtavarez first of all outstanding work in the last funding period. I actually had relatively high expectations, but you completely managed to blow them away nevertheless.
- 🙈: dtavarez
-
lehnberg: Second: I'm very much in support of you continuing on your path in the next quarter. So:+1: From me. Excited to see what will come out of it.
- 💯: privacybydefault
-
dtavarez: Thanks.
-
lehnberg: Third, and this leads into a wider question for us all here. How do you see this evolving in 2021, have you had any thoughts about it?
- dtavarez: Could you be more specific?
- lehnberg: What happens after q1?
- tromp: We have several wallet rfcs lined up... That could result in some more tasks.
- 👍: dtavarez
- dtavarez: Ah ok, for 2021 I plan to keep collaborating as much as I can. I also want to learn as much as I can about all the technical details of grin, so that I can tackle more tasks..
- 💪: joltz, phyro
- lehnberg: Nice.
-
antiochp: As @tromp said - there is going to be a lot of opportunity for wallet RFC related work.
- 💯: dtavarez
-
lehnberg: Let's see if by the time the next funding request expires, we can have something figured out that allows you to continue to make meaningful contributions on a longer term to the project.
- 💯: dtavarez, privacybydefault
- dtavarez: Looking forward to it!
- 🚀: lehnberg, paouky, joltz, privacybydefault, tromp, cekickafa
-
paouky: Looking forward to seeing what you'll accomplish.
- lehnberg: Anyone here against this funding request, speak now. In the meanwhile, given the sentiment voiced by everyone as being in support, we consider this approved and move on with the meeting!
- 🚀: antiochp, jaspervdm, phyro
- lehnberg: Congrats @dtavarez. 🍾
- dtavarez: Thanks! 😊
- paouky: Cheers.
-
antiochp: Ok 5.0.0 status: #287
Rc.1 is out. Next step is final release scheduled for jan 5.
-
jaspervdm: Yeah so unfortunately looks like we are going to need another beta and/or rc for the node.
-
antiochp: Want to give a quick summary?
-
jaspervdm: Yeah I have been testing with real testnet nodes and unfortunately a bug slipped in.
-
tromp: Glad to hear you found in time.
- 👍: joltz
-
jaspervdm: I'm doing additional testing. Will have a pr up by tomorrow.
-
antiochp: This is limited to pibd related code (which is effectively opt-in right now)? "opt-in" as in not actively used or exposed.
-
jaspervdm: Yeah, but its on the side that generates the segments. So important we get it in 5.0.0.
-
antiochp: Yeah agreed - I think assuming the fix is relatively small there should be no issue re-releasing rc.2.
-
jaspervdm: Yeah it is small.
-
antiochp: (and limited in scope).
-
tromp: Btw, is there a setting to sync only by pibd (and fail if no peers support it)?
-
antiochp: There will be I think, but not yet, no way to actually sync via pibd.
-
jaspervdm: 5.0.0 can only generate and send the required pibd data, not actually sync from it.
-
tromp: Oh, thought there might be a way to test sync on testnet.
-
jaspervdm: Not yet. But the idea is that once that is built, we can do so without requiring all nodes to upgrade again.
-
tromp: Ok, so all 5.0.0 nodes will respond to pidb requests.
-
jaspervdm: Yes.
-
antiochp: Ok so assuming everything goes smoothly today and tomorrow we can aim to tag and release
rc.2tomorrow? Is that reasonable? -
jaspervdm: Yes I think so.
-
antiochp: Which I guess is a good segue into my comment on the agenda. We don't necessarily need to wait until the last minute for the final release - there is no ar tweak to go in.
-
antiochp: So does jan 5 make sense to final release?
-
antiochp: Why not earlier?
-
jaspervdm: We could, but given the discussion above I'd like to wait a bit after releasing rc.2. So would have to be after christmas?
-
antiochp: Yes that makes sense. So maybe jan 5 is still most convenient time to do this.
-
antiochp: To maximise time for last minute testing. Without needing to do a 5.0.1 patch before we even reach the hf.
-
antiochp: Anybody else have thoughts on this?
-
jaspervdm: I think jan 5 is fine.
- 👍: antiochp, joltz, lehnberg
- antiochp: I think I naively thought this was a simple fix - but there is some tension between a couple of different issues here. We disabled http(s) by disabling listening on 0.0.0.0. Which I had not fully realised.
- antiochp: So its not trivial to re-enable this. At least that is my understanding now.
- jaspervdm: Yeah, its complicated. We would need another type of foreign api that only exposes the coinbase generator. Because otherwise we expose the receive tx endpoint, effectively enabling http again.
- antiochp: So short term I think we are stuck with the api on 127.0.0.1 (with all the hassle this comes with in a container). But something we want to revisit in q1 I think.
- dburkett: Honest question. How hard is it to just expose a new foreign api? We have 2 full-time devs, and 3 weeks until hardfork.
- dtavarez: But I think, maybe I'm wrong, the idea is to expose also the owner api.
- joltz: It's definitely worth putting some thought into. I was naive as well with this impact from disabling https. Want to make sure we get it right.
- dtavarez: I want to better understand this topic; the main goal of binding on 0.0.0.0 is to be able to connect to the node from any terminal inside a network (virtual or physical), right?.
- antiochp: Main rationale is for docker/containerized deploys. So 0.0.0.0 can be used across containers. Workaround currently is to run an in-container reverse proxy or similar.
- 👍: dtavarez
- antiochp: Which is perfectly fine, if not ideal. Api is currently split across owner/foreign. If we are considering splitting it 3 ways then I think we should take a step back and work out exactly what the split should be. And how different aspects are secured.
- jaspervdm: Right, the container argument also holds for the owner api.
- antiochp: So would definitely prefer not to rush anything in next few weeks.
- jaspervdm: That is something to consider, yes. But I do not think we should do this last second.
- antiochp: We should think about what an ideal api would look like. And we should prioritize this but its not worth rushing.
- 👍: dtavarez
7. Aliases for wallet transaction rounds
- tromp: I propose adding aliases to existing tx step names. Which are arguably somewhat arbitrary, and even overlapping. So the aliases in https://forum.grin.mw/t/transaction-round-naming-challenge/7886/48. Are all of the form step-flow. Where step = 1. Request 2. Offer 3. Accept.
- 👍: privacybydefault
- tromp: And flow is bill or payment.
- antiochp: I need to think about these a bit more but personally find
offer-billconfusing. - tromp: That's what happens in restaurant after you ask for the bill. They come bring it by your table.
- antiochp: Yeah - then you make a payment.
- tromp: By accepting their bill.
- antiochp: Personally I think of it in terms of the bill simply stating what I need to pay.
- tromp: The offer is the party signing first. And accept is the 2nd party signing, completing the tx.
- jaspervdm: Hm I am not sure If "request bill" is more clear to me than just "send". If I want to send money I use "send".
- dburkett: Real-world transactions are a 2-step process. Trying to come up with 3 steps will always result in disappointing wording. Imho, what we have now is probably about as good as it gets.
- 👍: dtavarez
- dburkett: Despite the many problems with it.
- tromp: But request-offer-accept is maybe best wording possible for 3 steps we're stuck with for now.
- dburkett: O, I just read this.
- jaspervdm: But using "request" to send money seems counter intuitive...
[...]
The meeting continued to further discuss transaction round naming, without arriving to any particular conclusion or consensus about the most appropriate naming.
None.
Meeting adjourned.