Could you point me to the exact proposal that was ignored and unaddressed?
You suggest others ignore these, but if my memory serves me right, that’s not true. First, Kurt was the person I communicated (by far) the most with on Grin. We had private discussions daily around MW and Grin and were reviewing each other’s ideas (most of which were never public) and learned from each other a lot. I know that at least myself and tromp (iirc antioch as well) reviewed both of his kernel uniqueness proposals and some reviewed 2-step ideas as well. The discussions are all public I believe some happened on keybase. You’re talking as if they did nothing bad and were treated badly. I consider Kurt a friend and would be more than glad to see him return, but this doesn’t mean his behaviour was good, it most certainly wasn’t. I even remember him admitting that on some occasions. It’s not like one side was a saint waiting for a response and the other side ignored things. Things were heated because the individuals took a specific (unproductive) approach to things. I’m only talking about the first two names on that list here.
This is one of the reasons I wrote above the OC reacted poorly. But you have to look from the other side as well, how many people were defending them when they in fact did not deserve what they were getting from the community? You will now ask “and why did they not get the support?” to which my only answer is because people didn’t understand the context and implications of the protocol changes they refused to make and were easily convinced by the popular community members the changes were good.
Because David, Davies, Kurt (a little less so) and others convinced everyone that OC was wrong and wanted to start a rebellion against the OC using the words they will “destroy Core”. It’s extremely easy to convince people that an idea is good, I could probably convince most of the community the scripting method I described a week ago is great and everyone would believe me without a single person understanding what it actually does. There’s a very big asymmetry of knowledge regarding the protocol between the community and the developers and only a few would be able to see why this is bad. You can guess which ones would be able to see the flaw. I could organize a rebellion against them. Does this mean others are dumb or less intelligent? No, the knowledge asymmetry and the way people react to “shiny features” is just a part of the dynamics we live in. I could similarly be convinced something is good on a subject I’m not familiar in when in fact, it wasn’t good.
I have not. My experience comes from my own usage and protocol understanding. I’m not good at this and hence I don’t do it. But I can definitely tell what could be improved which is why I’m trying to get feedback on the contract prototype.
Who is “we”? I have stated many times that I don’t plan on investing my time in supporting a specific exchange. I’d rather have something that makes it simpler for them to make a robust integration. I believe a path forward is to unify the transaction building and integrate with manual slatepacks. Introducing an additional “network must be up” assumption (e.g. Tor), doesn’t seem to be a good idea if you want to make it robust. The user and the exchange already have a network connection through a website, any additional may make it faster, but also less robust.
That’s quite an accusation. Could you point to an example of when I (or others) didn’t listen to people because I thought I was smarter than them or where I had “the smartest kid in the block” attitude?
Are you sure that’s what’s going on and it’s not just me investing time where I believe I can contribute the most? For instance, the reason I didn’t answer to GrinTurkey above was because despite asking 3 simple questions, I received 3 separate answers none of which answered a single question I asked and on top of that he made unsubstantiated accusations all over. It simply felt I won’t be able to achieve anything if I engage in such a conversation so I went to do other things instead.
It’s very easy to say “you have to do X”. The issue is time, skill and motivation. I have a limited amount of free time. If I start being a support person for Grin, this means I’ll be less focused on other things. If I had done this for the past few years, it would mean we would have less or worse of the following:
- the contract prototype or research in this direction
- mwixnet
- what is grin/why grin and other documenting of ideas on grinvestigation
- some replay solutions and discussions
- reviewing of other ideas etc.
It’s a tradeoff. I have no idea which one would be better for others, but I do know I’m not good at the things you accuse me of not doing and doing that would, for the specific case of myself, be a less productive path. Since I’m not good at that task, my approach to help on the front of making it easier to use (which is a passive support I guess?) is by eliminating friction when building a transaction by unifying concepts and making the process itself simpler. I believe the contract prototype to be a step in this direction. It’s not taking user experience into account (apart from mine), but it does seem to make the process simpler and more robust if done right.
This doesn’t mean RSR is bad and it certainly doesn’t mean removing it is a good idea. Was there any other developer that wanted to remove RSR apart from David who was clearly against RSR? Have you ever thought about what a 5 party transaction would look like on Grin? If you think about a SRSRSRSRSRS transaction with 3 senders, only one of these senders will be able to finalize it. I don’t see how the solution is to potential RSR problems is remove RSR because the same “issues” appear in a context of multiparty transaction. Would it not make more sense to separate the setup and sign step and generalize transactions over this to potentially get multiparty support and have a unified flow for a case of 2, 3, 5 parties? I can’t say this will come out, but it seems like a better direction to research than to just say “X is bad” without thinking about what the underlying problem is. The other suggestion was to turn RSR into SRSR which, again, doesn’t tackle the root issue.
Did we really do that? I don’t see this as being the case at all. As far as I remember, I personally have reviewed almost every idea that appeared regardless if I thought it was a good direction or not. This includes NITX, different kernel uniqueness proposals and many others. And as stated above, so did people that were on OC back then. The disagreements came from the fact that after the review, OC members said the idea was not a good fit for Grin. I was an outside observer, but it seemed that any non-engagement was a product of disrespectful communication on the other end and these discussions are public on the forum/keybase because I remember seeing this.
I think it’s great we have some people doing that. Did you have any specific change in mind here that you’d like to see and it’s not coming through?
I think everyone agrees on this. My view on the state is that those that are around work on and what they believe to be the best direction. Speaking for myself, if I reflect on the contract idea, I believe I initially explained the symmetry of the flows years ago and the idea didn’t move anywhere until I started coding the prototype myself. The time I have, I invest in this. Someone else will invest it in what they believe. If we’ll agree this isn’t a good path, I’ll drop it and start working on what I believe is the second most important thing. Of course there are other tasks everyone contributes to (e.g. reviews or new ideas), but time is limited and not everyone can do everything, so you have to cut some of the items off the list. The main thing we have to do is to keep supporting each other to contribute our free time to Grin in a productive and judgment-free manner. It’s incredibly easy to turn against each other, but things can always get resolved in a productive way if both parties are open to a constructive discussion.
together and laugh at all the bumps we’ve had on the road 
)