UpLink proposal #424
UpLink proposal #424
Conversation
|
Hi, all, One quick note about this PR: there was a similar PR before, but the reviews were so extensive that we decided to open a new one. The old PR does not really contain any necessary information, but it feels better to clarify that and avoid any further confusion. Thank you. |
|
Thanks for the effort you've put into this @andre-francisco. You're right, this was very well explained and easier to understand. I only have these last remarks:
|
|
Thank you for your feedback, it makes a lot of sense. I reordered the milestones and included a table with the order of the deliveries, I think this way it should be crystal clear, both for order and duration. Also, the Communication Protocol (which is now M1) was so expensive mostly because I was playing on the safe side with respect to the security assessment; those things are usually hard to predict because you don't know what you'll find in advance, but perhaps my hesitations were exaggerated; I've reduced the total cost. Anything else you think I should do? Your feedback is super valuable, thank you, once again! |
|
Looks good to me! The order of milestones 1 and 2 is not the same as in the table, I don't think this was intended? I'll share the application with the rest of the team. |
alxs
added
the
ready for review
Updated UpLink Proposal Fixed order of deliverables
|
@alxs you're right, I missed that. It's fixed now. Thank you for status update, we'll be looking forward for next steps! |
|
Just a note in case there's any more feedback: no need to force-push any more. This is just for the initial PR, subsequent commits are useful as they allow us to see the changes. |
|
@alxs Understood; I'll stop rebasing in the future. |
|
Since each chain built with substrate can use custom modules, and therefore, provide custom functionality, will your communication protocol be extendable to allow anyone to implement a non-standard (e.g. not included in Polkadot) queries/Tx's? Otherwise looks good 👍🏼 |
There was a problem hiding this comment.
Thanks for the application. I have a few additional questions:
- How do you plan to track the spent resources via substrate? I think this is one of the biggest problems to solve, because you quickly reach the limits of blockchains (tps) if you try to archive this in a way that can not be easily exploited.
- In general, what do you plan to store on-chain?
- Currently the relayer server seems to be rather centralized. Did you consider using something like an off-chain worker for this? How do you plan to incentivize people running the relayer?
|
@mmagician yes, it will. Citing from the proposal: "In future reviews, this logic should be optionally integrated directly into Substrate, with the intent of having Substrate and off-the-grid devices communicate end-to-end, without the need for mediators. However, due to the complexity of that endeavour, the Relay Server will replace that setup for an initial version." So the idea is that this communication protocol is made available as a Substrate module. That will probably be our followup for the General Grant program, since the implementation should be far more complex. For now we're using a Relay Server to replace that setup, but it's not ideal. |
|
@Noc2 thank you for your questions, I'll leave some notes:
In this version the nodes are not incentivized. Citing the proposal: "It’s notable that this constitutes a relaxation of the UpLink project in many ways. In its entirety, the UpLink project proposes an incentive-based multi-hop mesh network system built on Substrate, enabling devices to communicate peer-to-peer and be rewarded for their cooperation. This project, however, proposes the much simpler non-rewarded proxy alternative [...]". As for future versions, the incentivization model is not designed yet, but we're considering a model based on Lot49, a mesh network incentivization model by goTenna. We're considering this as a followup for the General Grant program as well, or at least to have progress on this until then.
Whatever the deployer wants. This is a generic system that enables devices to communicate, but it's up to specific implementations to decide what to do with it. That is, we work with connectivity, what that connectivity is used for is project-specific.
The Relay Server will not be a part of the end system, but it will work as a means to implement the protocols and all the necessary logic until we get to the point where this is fully integrated into Substrate. It will work only for some use cases (e.g. the Relay Server can be trusted), but not for the general case; for that we'll need to go ahead with integrating the protocols as a Substrate module. |
There was a problem hiding this comment.
Thanks for the quick reply. Yes states channels seem to be the best solutions for this problem at the moment. You should potentially take a look at cChannel-substrate by celer. Just one more question from my side: Do you already have some concrete initial use cases for your technology in mind?
|
We'll definitely have a look at cChannel-substrate, seems interesting. Thank you for the suggestion. Regarding the use case, yes. We're working with a major payment processing company to enable digital payment processing in markets with poor or expensive connectivity, where digital banking and the usage of digital wallets is growing exponentially. This integration with Substrate will work as a key component of such system, and our goal is also to bring these payment processing companies closer to the crypto world; this integration should achieve just that. |
There was a problem hiding this comment.
Thank you for the answers @andre-francisco. Looks good from my side, wish you luck with the development!
|
Congratulations! As part of the Open Grants Program, we want to help winning teams acknowledge their grants publicly. To that end, we’ve created a badge for projects that successfully delivered their first milestone. Please observe the foundation’s guidelines when making any announcements; in particular, don’t announce the grant publicly before you've completed at least the first milestone of the project. |
Updated UpLink Proposal Fixed order of deliverables Co-authored-by: AndreFratelli <andre.fratelli@hotmail.com>
|
Hey @andre-francisco, care to share a quick status update, along with an ETA if possible? As long as you're actively working on the project, delays aren't a big problem, but please keep us in the loop. Note that if we don't hear from you within the next two weeks, we will assume you're no longer interested and terminate the grant. |
|
Hi, @alxs Apologies for the delayed response; you are right, an update is in order. The project is alive and kicking, and we've been making substancial progress in the development. You can see the latest progress here; I just committed the latest changes. What happened was that we had another project coming in from a major customer, although one that is overlapping with the grant. As you surely understand, I can't reveal any details on that specific project, but I can give you some additional pointers in private, so do feel free to schedule a call if you feel that's important. For the most part, the requirements for the project changed greatly. These are actually good news, since we'll be delivering more than what we had initially planned, even if that means a substantial delay in the deliverables. The two projects overlap in a great deal (gross estimate, perhaps around 80%), so the progress that we're making there is also quite significant for the grant. The downside is that we'll start focusing on the grant only as soon as we deliver this project. With respect to timelines, we have another month and a half ahead of us for this delivery, so I would say that we might complete the final deliverables for the grant closer to the end of the year. As a rough estimation, mid December should be a good pointer. We'll know better as soon as the project with the customer is concluded. I hope this makes sense and that the grant is not cancelled, since we're still very much interested in pursuing this. |
|
@andre-francisco that is good to hear. No need to disclose more details and we won't cancel the grant as long as you're working on it. We would normally ask you to submit an amendment with updated delivery dates, but it sounds like in your case more changes would be required and you'll be in a better position to write the amendment when you've further advanced with this overlapping project. So let's just wait for the moment - when you know how to proceed, I encourage you to not only update the delivery dates or simply submit, but to take some time to first adjust the proposal to what and when you want to deliver as this will likely significantly facilitate the delivery. Also keep in mind that most teams submit milestones separately, which allows you to get feedback earlier on and us to evaluate the grant incrementally. |
|
That is great to know! Reviewing the project proposal would be tricky at the moment, since all of our resources are currently allocated. But I'll make sure to update the proposal as soon as we can. On another note, the first deliverable is actually ready; none of the other deliverables apply right now, but would it make sense to move forward with the first deliverable? What would that entail? |
|
@andre-francisco sounds good! You can certainly submit the first milestone if it's ready - the only reason I can think of why you'd want to wait would be if you expect the rest of the project to change in a way that the milestone wouldn't fit into it any longer. As long as that isn't the case, please go ahead. The process is described in the milestone delivery repo. Please take care to complete documentation and test suite for the parts of the project that you intend to deliver and then simply follow the instructions! Let us know if you have any questions. |
|
@alxs thank you yet again! That reminds me: the API docs should provide the necessary coverage, but not the tests. I'd assume this is grounds for dismissal, so maybe it doesn't make sense to go forward at this point. Unfortunately we'll have to continue to delay the project until we meet the proposed criteria. Either way, we're still working on this and intend to continue to do so. |
|
@andre-francisco following up here, I hope everything's going well. Do you have any news on the project, and could you give us a quick update on the timeline? Depending on where you stand, it may make sense for you to submit that amendment now. |
|
@andre-francisco is this still on your roadmap? Note that given the delay and as we haven't heard from you in a while, we'd terminate the grant if we don't hear from you in the next 2 weeks. You're welcome to apply again at any time. |
Grant Application Checklist
project_name.md) and updated.