dtavarez : @defistaker any brief introduction about the first topic?

• defistaker : Well. it came up on the video meeting that mcmmike held. In the meeting, nagini had expressed some ideas to increase grin's public interest. @mcmmike suggested to continue discussion in today's meeting; I think nagini has not joined the meeting yet.

defistaker : He(nagini), talked organizing a team of 10 people for twitter, then start to twit in an organized way at the same time so that it would have a more powerful effect

• dtavarez : mm nagini isn't here though

phyro : I think a lot depends on who's handling the social media. Positive content for a project done the wrong way can deter people from even looking at it - that's what makes me not even look at 99% of the projects. You'd need a high level of maturity and a good way to present things. I think Paouky was an example of someone doing good tweets. I'm not sure I'm explaining this well tbh, but I hope you guys know what I mean

dtavarez : My opinion is that I think things will flow with more active contributors. We tried to create sub teams before and I'm not sure if that was successful.

jankie1800 : there are many exciting developments happening in the ecosystem; something of interest may be bringing back the 'Grin Community Project Day'; a place where developers can demo, showcase, and talk about their projects,receive feedback etc; perhaps even use the video conference platform. (idea sourced:). examples would be grinvention/ grinnode live speaking on their ongoing projects. Also wallet devs speaking on their projects. Just something to think about :) and I like the additional ideas, anything to boost engagement I am all for

dtavarez : I'm not sure we have enough contributors to do that

defistaker : I agree

dtavarez : my opinion for extending grin ecosystem is that we need in person meetings all over the world, we need to grab a beer or two and talk about crypto

sheldonth : I would host an in-person meeting in NYC someday soon if people are interested or nearby

defistaker : I think we can postpone this issue, come back later if nagini decides to join

dtavarez : I agree

jankie1800 : just a quick update on workflow. Defistaker and I agreed on delegating newsletter and meeting transcription over to my tasks; while Mr.staker will continue to update the ongoing agenda items. I think this will allow for a more transparent workflow, and bit more more efficiency through a more focused process.

defistaker : I will be more involved with website and other tasks

jankie1800 : before we were juggling these tasks back and fourth, and like defistaker says this will allow for more focus on our individual workflow

dtavarez : what about the finance report? any idea when are we going to publish the CC spending?

cekickafa : grin spending reports not published too I think

jankie1800 : this needs to be addressed certainly. I can commit to working out best how to organize this into the GrinCC github

dtavarez : are you guys going to manage that too?

jankie1800 : at this point it has been unaddressed, but i think we all agree it should be a priority

dtavarez : can we confirm is publishing the spending reports is part of the tasks?

jankie1800 : if you don't mind Mr.Staker. I can tackle this? :+1: defistaker, cekickafa

dtavarez : probably by the end of this would be nice to have a report. can that be a potential estimate? end of the Q1 2022?

jankie1800 : agreed.

dtavarez : thanks! any other updates?

jankie1800 : just a note; This adjustment doesn't change our collaborative workforce as I believe we remain committed to working together through assisting each other when and where needed while further communicating ideas and strategy.

defistaker : I have added a council info to grincc docs. I will add this to home page of website, if approved/corrected I have done some fixes on website, only the dark mode problem is left, I am dealing with that right now. Google chrome somehow converts black color in grincc logo to white in dark mode...

dtavarez : at the end I think it is important to have transparency on what we have been doing, a place where anyone could go and read the meetings notes, the spending, agenda, etc. that's my opinion.

dtavarez : should we continue with the next topic?

jankie1800 : redbean! but I know that it likely be too buggy for serious development

dtavarez : @sheldonth is here, right?

sheldonth : I am, yes

dtavarez : cool, would you mind to introduce the topic?

sheldonth : Yes, so on this topic, which I know is a bit of a hotbed for debate since there other very nice GUI wallets live in the field at the moment, but I wanted to see if we could coalesce around a possible tech stack for a UI on the rust grin-wallet code. We had discussed this with yeastplume a few weeks ago, and he mentioned that in a historical context he felt like it was a mistake not to have a GUI on the reference wallet.<p> John Tromp had recommended a project called redbean, which I am just digging into this morning, but it's a fabulously elegant want to have a truly run-anywhere double-clickable web powered UI (must like electron) but significantly more lightweight that looks really nice.@jankie1800 I just watched a youtube video from the project author who says this thing is ready for production use and she does not look like the type of engineer that would make such a claim lightly. There is some serious software engineering under the hood in redbean. I like it a lot</p>

jankie1800 : that's an incredible product, really is. I did notice that near the end she mentioned something about read/write not being fully functional on windows at the moment

dtavarez : what about Tauri?

sheldonth : I still need to look into Tauri - perhaps this meeting is more about assembling a list of options. I could do an indepth research project on each of them before the next meeting.

dtavarez : or Orbtk?

sheldonth : Yes, that's another. There was some discussion that Orbtk might not have enough a future maintenance schedule around it for our needs. Like, it has just a few authors and they seem not so active.

phyro : one question I have is how do 0-day browser exploits affect the tech

dtavarez : not much because what is been distributed is the engine not the browser

sheldonth : I concur, I don't think 0-days in the UI are of too much concern. Well, can we all concur we aren't interested in electron? It's so heavy, so dependency laden, I think it just doesn't feel right for us.

jankie1800 : @sheldonth are you thinking of including the node built into the ui as well? because if I'm not mistaken that would set this apart from the already developed wallets.

sheldonth : so i'm picturing a system where you can elect to connect to a remote node (live grinnode.live) OR you can choose to have the UI spin one up locally, yes. But yes, jankie, I'd like a little feedback there too. I'm thinking that this UI does have the ability to spin up a node for you - thoughts from the team on that?

phyro : I like the option @yeastplume mentioned Monero has. You can setup a local node during the install (or maybe when setting up the wallet) or use a remote one.

sheldonth : correct phyro, that's the idea

dtavarez : what do you mean with spin up?

sheldonth : fork an instance of the grin executable on the local machine, and connect to it with more interaction from the user than that, no more

dtavarez : Grin++ is doing everything you are mentioning in the post

sheldonth : correct, it certainly is.

jankie1800 : while grin++ has node feature I believe the point is to build out ontop of the Rustlang reference.

dtavarez : Grin++ is not supporting remote nodes, and probably it will never support them

sheldonth : @dtavarez by no means is this a slight on grin++ - nor do I intend it to be. I think grin++ is great software and a boon to the ecosystem. But I also don't think it's existence precludes the undertaking at discussion here. Really, the challenge as I see it right now is choosing a tech stack. And maybe that just means we pick one and start building. If we like what we get out the other end, then we keep it - if we don't - then all that was lost was some developer hours

dtavarez : I'm an advocate of people contributing with fits better for them, I just want to say that. if members find that it is time to have a UI in the <mimblewimble> that's fine

defistaker : is this new wallet gonna work on mobiles as an app?

sheldonth : @defistaker good question- I think aiming for mobile compatibility initially could be difficult. The aim is a single "download, click, run" executable for mac/windows/linux/freebsd/netbsd- where the Ui works on all those desktop platforms

jankie1800 : sounds nice but the question comes down to man hours at some point

sheldonth : Here's a proposal for moving forward: I will investigate, in this order: redbean, orbtk - and put together a very minimal proof of concept. Let's see - can that single "download, click, run" system be built that works- If it can, we'll reconvene in some time and choose which one it seems like works better

dtavarez : but why not to include niffler into the mimblewimble repo if xiaojay agrees? and improve niffler from there? and IronBelly? those two wallets are using the rust node- this is not clear to me

sheldonth : Niffler's stack is electron and react?

dtavarez : I guess yes

sheldonth : I need to take a closer look at Niffler I'm not too familiar

dtavarez: cool

sheldonth : Just as a screen cap from the redbean demo, electron is very heavy. I have an idea that perhaps it could be avoided. Okay, so let's table this discussion until some more investigation of the possibilities is completed.

dtavarez : I think it will be totally unfair in my opinion

sheldonth : What's unfair?

dtavarez : not supporting the current UIs projects; if they agree on moving the current UIs to the mimblewimble org, I don't see why not to do it- last commit on Niffler was on May 29, 2021. and @i1skn is still working alone

sheldonth : Hmm, ok, duly noted. I will take a closer look at Niffler. Perhaps a small working proof of concept might be the best way to get the community to coalesce around a particular approach to putting a UI on the reference wallet. I will not be unfair to the technology that's already out there. I assure you.

phyro : I can't say anything about this tbh. I think this is more complex than it looks at first. We'd need to have a clear goal of what we want from a "reference wallet"

dtavarez : I though that we were not interested in UIs- but probably that changed and it is irrelevant. But still why not support ironbelly? or Niffler- and I'm sorry I don't want to bring any divisive conversations

phyro : I think this is less about support and more about the design of what we may label a reference wallet but we haven't really had the discussion how people see this. So this is just my random thoughts design here isn't meant as UI but rather system design- It's ok, respectful disagreements are welcome

sheldonth : I agree phyro, it's system design all the way down.

dtavarez : grin is not like that, it is not supposed to be like that- there is no centralized entity dictating anything; if we want to have an agreement on something we need a RFC and all devs must follow them

sheldonth : let's look at the history of bitcoin for some guidance here: bitcoin-qt was launched in 2010, and the Qt ui in it's basic form (gray, no color, just a few buttons and checkboxes) has served it well for a very long time. It's very robust and very lightweight, and Qt was a system decision that bitcoin stuck by and continues to this day. If we "bond" the reference wallet to electron - that's a system design choice that will be with grin for a long time to come. Having other wallets use electron is fine, just as other bitcoin wallets use electron, but what we call the "reference wallet" and what we use to build the UI is a system design question with some far ranging consequence for our users.

dtavarez : agree we want a reference UI, I've posted about it before, and I think that's great but a reference UI could be a set of designs and templates, nothing more. not a full GUI written meant to be run and that's what is being suggested- those are two different things

phyro : I think what sheldonth wants to have is a minimal UI on top of grin-wallet that would last for a very long time, rather than a design template.

sheldonth : yes that's exactly correct @phyro

dtavarez : and that's Niffler

sheldonth : Okay, for the sake of time let's table this and move into the next topic at this meeting. I think this was a healthy discussion and perhaps if some other OC members read this at a later point and want to chime in with feedback that'd be great. But I'm glad we have a discussion here on the record about it

• dtavarez : but still that's not true,(minimal UI) is not what is written in the forum post, but we can continue with the next topic

yeastplume : Just back on the wallet for a second, we do have a reference implementation (the CLI) and we're fairly unique in that we've spent a lot of time developing an API that cleanly separates any wallet from the core implementation. This API can be called over a socket or linked directly, so there's little danger of any particular wallet becoming 'bound' to grin wallet- It's a very clean separation at the moment. Any wallet that I'm a part of producing will keep using that API, and if any parts of the API prove deficient than the API and underlying core code will be modified. So in my mind, it doesn't matter what the UI portion of it is coded in. My choice personally would be heavily influenced by whatever is easiest for UI designers and frontend developers; it's unlikely I'd use QT or any rust based libs or anything that requires front-end developers to also know Rust or C++, it's asking way too much of an individual

defistaker : @philippnagel added this to agenda

jankie1800 : I wonder if it is accurate to assume that If Taproot enabling scriptless scripts with BTC then there could be some very interesting cross-chain use cases

dtavarez : about Scriptless scripts with mimblewimble anything else we can find out about this?

cekickafa : mimblezimble phyro posted

phyro : I'm not sure whether there was a specific question regarding these, but scriptless scripts are possible if you have Schnorr signatures, so we can still do them on Grin, but we haven't seen projects doing that

dtavarez : probably we could compile more info about this on a forum post

dtavarez : @defistaker probably we can conclude today's meeting :)

Meeting adjourned