#Regarding S Class submissions
1 messages Β· Page 1 of 1 (latest)
I think the team is doing a manual review now. I'm not sure resubmitting all S classes will be ok.
I can suggest team provide an update on the next batch faster so the rejected task can be submitted again before the deadline.
Also Team is saying they have script automate read the sheet and update point on Nebb already.
What we can do now for tasks already submitted is they need to keep their RPC/explorer up until the end of SE
The team can do random checks and deduct points for that.
I don't think we can do this with IBC because maintaining old IBC is very difficult when chance is halted.
If task S takes too long to update, then at least the NEBB should be updated continuously. Currently, it is stuck at block 113,304
Checking manually is the best way.
I think its way behind 113304 it has not been updated for 10 days
Yes resubmit works make more fud , and some ibc channel live at several days because it's small trusted periods, but i think check rpc easy can make a script
Prioritize low-submission high-value tasks beyond date order.
manual is the only way. the scheme you propose is a gift to those wanting to automate lots of accounts
that being said, why not involve community members in checking the simpler tasks? I wouldn't mind giving a hand if needed, and I'm sure others could be on board as well
RPC, IBC and Indexers should be evaluated and even health checked automatically
Just send the wallet address and an initial tx on the destination chain and you're done
Or the community already has an online IBC channel scanning tool
yeah it's kinda easy to automate
IBC health check is not practical since IBC realyer costs so much toknes.
The rest can be done easily.
Agree on this.
This is smart
Just to take some of the backlog out
agree, we can check the RPC later
not if you only relay your own messages not every channels
you can add the filter policy to decrease the cost
example
[chains.packet_filter]
policy = 'allow'
list = [
['transfer', 'channel-3850'],
]
Yeah. I know. But it would be better to relay others to improve user ex.
Hire an intern for 2 months, probably the most efficeint way to tackle the problem.
- Manual review
- (s)he learns the project in the meantime
- you get a boost on submissions check
I dont think automating is a good idea to implement. From a perfect world perspective, it could help, but it would cover maybe just RPC and partly IBC.
You can provide guidelines on how to format a submission however, for standard things :
- RPC : provide the link, /status must be working, ...
- IBC : channel must have new IDs, provide a tx id on mintscan that show a packet/tx got through that specific channel. Do we intend that the channel is always open and working ? maybe maintaining a working channel could give more points (coz now, it more a "fire and forget" task)
And so on.
The difficult part, with the growing number of submission, is the deduplication.
Another approach could be "do a community check first" :
-
You dump all submissions in the spreadsheet, as soon as possible
-
You assign them a "community review" tag (not YES/NO)
-
People can comment on the quality/working task. Wait for 2-3 comments that point in the same direction (from recognized community members), then
-
"Team review" tag => YES/NO
-
Reward the people who take the extra mile to spend time validating properly, there are already some people in here who do that just to help
That way, duplicate (re)submissions are filtered out quickly, rubbish submission too. Spork can only validate that is shown to be working
It would have to be selected community members.
You can't just open up submissions for community review simply because of bad faith actors. You introduce even more variables into the equation by allowing community review.
The review has to be independent from the community and maybe a hired third-party as you recommended.
I don't think it's so hard for ibc, rpc or indexer. All can be done by script. Especially for rpc and indexer, no need for human verification. As for ibc, it can also be done by script but more complicated.
Team just needs to review others, which is much less than these.
IBC : you just have to send a tx through the channel, if it arrives on the other side, β
I don't want to be hard on team and I realize there's a lot of work, but feel realistically that checking an rpc takes all of 1-2 minute's work. imo what's needed is more hands on an overwhelming workload.
We are aware of the team's hard work and we appreciate it.
imagine the number of bots commenting π
that's why I added (from recognized community members)
π Any progress on the S class review? Been waiting for 2 weeks now
I can understand the team's thoughts, after all, I myself am also annoyed by dull, uncreative, and repetitive tasks. However, it seems they also lack sufficient manpower for review. Not all reviews need to be automated; using scripts to assist in the review process can greatly accelerate progress.
sure, I'm just skeptical if that will decrease the workload that much. did you have a telegram bot btw?
yes. https ://t.me/Namada_Validators_bot
thanks. this is your work? I'll check it out, could use telegram monitoring
Yes. Plan to add more.
@here to be clear, we're looking for feedback. thinking that we:
- standardize the format for RPC, indexer, and IBC submissions
- participants review the sheet to see if their submissions is marked 'resubmit'
- "resubmitters" use the format to resubmit
this would only affect the above submission types, and from Feb 28 and onward (not Feb 27 and before). other kinds of submissions (like github and explorer) will not need resubmission.
pls review? and comment here or on the doc https://docs.google.com/document/d/1VDc0Xaa4mZPSoyG6tVbqFBZze6HFtnjNC2BZDIQi1TU/edit?usp=sharing
to be clear, this has not yet been implemented!
If I sent the RPC according to the standard after February 28th, will I still need to resend it?
you will not!
that's an important point
we'd only mark entries that are in a different format (because we won't be able to use automation to verify them)
RPCs: this endpoint is enabled by default once the node is started, just posting ip+port doesn't mean "support as service". It should have a domain and reversed proxy at least, and be synced most of the time. Otherwise, it is useless I agree on this.
at least a domain and reversed proxy. Also the node should be synced when checking. As for uptime, it can be monitored but a little late imo. Because the testnet is about to end in 2 weeks? or shorter?
hope the team can get through the backlog of s-class reviews soonπ«‘
very much agree
Dear Namada team. I have a question. I definitely think that score for my task of providing rpc endpoints was given incompletely. It may be a bug, or there may be an error in automatic distribution. I would be glad if someone could review this issue. It would be appropriate if I could contact anyone on the point distribution system side. Thank u
Sorry, of course, for my comment, but overall it seems like you create a problem for yourself first and then heroically solve this problem.))
When people say that the team is not keeping up with big data processing, it implies that someone is attempting to do so. As far as I understand, since March 8th, no one has even attempted to check the completion of community tasks.) And if you don't try - then undoubtedly, it's very difficult to check, and automation should be considered.)
was there talk of s-class submissions ending tuesday, or did I misunderstand?
I think they meant a week after the hard fork, the hard fork was originally supposed to take place on Tuesday and the deadline for accepting applications was the following Tuesday. In any case, I think we still have time to submit applications, since we are still waiting for standardization on the submission of IBC relayer
Reason: Posted a link
652 π§
you gave points for this dashboard, interesting point π€
which is that?
@here, how does this look? @frigid coral would like to begin testing this: https://docs.google.com/document/d/1VDc0Xaa4mZPSoyG6tVbqFBZze6HFtnjNC2BZDIQi1TU/edit#heading=h.288mufqjnksl
maybe it's helpful to know that we didn't create or begin this game, and now we're trying to fix it the comms/coordination issues π
Can we already send tasks according to the specified standard?
When the main team was working on the testnet, it was much more pleasant)
can you expand on that? would be helpful to understand
yes, it would be good for @frigid coral test
Do we even need more comments for the current test network?)) Disregarding technical difficulties, since the test network doesn't imply stability.)) But there are many questions regarding the organization, starting from poorly thought-out tables, conducting IBC checks when the network wasn't operational, lack of initial automation, and ending with reward distribution, as well as the selection of genesis participants, whose Discords have just joined the group, while old, proven participants were thrown "overboard".)) Actually, it doesn't matter anymore; we're working with what we have.))) Just a tiny bit of unnecessary feedback for anyone.))
Did I understand correctly, if I submitted the IBC task on March 09, then I must submit it again through the same form on the website, taking into account the new requirements? Even if it's identical to what happened before
@delicate wolf when we can expect a new batch from s class task ?
so should i resubmit my latest submissions?
i provided my gist link in the evidence section. is that okay? or should i resubmit the submissions?
how does this plan sound?
- during today, i import existing submissions up to today's date
- i run the script that will check all those that already match the updated submission guidelines we posted the other day
- i add all (processed and unprocessed) to the sheet
that way everyone can see the state of their submission... no more wondering if it was received, or if it's in a future batch, or been checked yet etc. and also people will be able to see if they were already accepted so they know they don't have to resubmit
Good plan π«‘
Great! When do you think it's ready?
i can start this morning, not sure how long it will take but aiming for by end of today (eastern time)
@frigid coral It's really great. thanks for your effort. I think there are much fewer other tasks (except indexer, RPC, IBC) that can be checked in short time. isn't true?
yes i would say indexer/rpc/ibc make up about 80% of the submissions
rpc and indexer checks are easy to automate, ibc has been a pain point so far because there was no guidelines on how or what to submit so they can vary a lot
@here: i've updated the sheet to include all submissions up to today, after parsing according to the updated submission format guidelines (https://docs.google.com/document/d/1VDc0Xaa4mZPSoyG6tVbqFBZze6HFtnjNC2BZDIQi1TU). we are at over 1800 submissions so far
- only rpc/indexer/ibc tasks were checked so far; explorers etc still need to be checked manually. so if your task doesn't fall into one of those three categories, you don't need to do anything further except wait
- if your rpc/indexer/ibc submission was marked 'yes', the check was successful and you don't have to do anything further
- if your rpc/indexer/ibc submission was marked 'no/bad format' please resubmit following the format guidelines above. (it doesn't mean you were rejected, just that the submission couldn't be parsed)
- next focus will be on going through the unreviewed (yellow) submissions and comments on the sheet, and then the manual review tasks, to give people time to check the status of their ibc/rpc/indexer tasks and resubmit if needed
- as always, there is opportunity to check the correctness of evals and make any updates
There were a lot of rpc submissions that were word-for-word identical with a http://ip:26657 address (see rows 950-980 for example) that, to me, look scripted, so i marked all that followed the same pattern as spam. but if this seems wrong, please let me know
Wow great
hey @frigid coral i think there's a mistake in my s class submission check. my rpc endpoint submission was submitted on 26 march (row 703) and it was checked as "working". but now, in row 1333, the same submission is checked as a bad format. please fix this
pk : tpknam1qzaqvxm6g4h7z34pgdqyzh3y4xevx072ednsfcujfza02knwrfkwqrgywah
Thank you, great job
mann there are a lot of ip:port rpcs in that sheet...
just made a couple of submissions. how often do you expect to refresh the sheet with the new format?
hello,How do I submit feedback? I also have some opinions I'd like to put forward
?
emmm
we're speaking of s class submissions, not submissions of opinions
with this sheet I mean
Oh, I apologize, I misunderstood
I am so skeptical of all those publicly opened RPCs with direct access to the host π don't kill me but I would not count this as a working service coz of 2 things:
- you expose access to your server opening the node to all vulnerabilities
- it is enabled by default just when the node starts, so the only that is needed is to know your address and port (but cmon it is default 26657 for 80% of them)
here is the recently updated list of opened RPCs, some of validators as well there: https://snapshots.liveraven.net/snapshots/namada/rpc-scanner.html
very much agree that the ip:port variants should not be awarded points. at minimum invest in a domain and configure reverse proxy
So right π― Only RPCs served from a domain should be accepted
@frigid coral
@novel bough agree with you the rpc should be configured with ssl.
I don't quite agree. I'm just a crew member, and my RPC is not a verification node. Why should I set up a reverse proxy?
Besides, I haven't set up SSL because the RPC data is originally public. Even if the signed data gets intercepted by internet service providers, what's the big deal? It was meant to be broadcasted anyway.
there's nothing wrong with running it like you are, but 1. it isn't providing it as a service in that format imo and 2. if that's accepted, everyone running a node qualifies by definition, as liver pointed out above
All I can say is that for crew members, your advice is utterly nonsensical. Of course, a verification node should definitely set up sentinel nodes. However, this is just a test network, so I don't see any reason to fuss over this, it's just like everyone randomly proposing and voting.
I partially agree about the domain name, it is indeed hard to remember without one.
I think you may want to tone it down a little. look I'm not saying you're running anything wrong. but the s-class is specifically for running namada infrastructure as a service, not just for starting a node. (pilot or crew is the same with respect to this)
that's what I think anyways, you don't have to agree with me
Hello. Can you help check #1184 again later ? My api has issue because my node was got issue with full disk. db is re-sync and will able to catch up soon. Thanks
My post-genesis node uptime keeps showing 0%, why ?
Is there a column of data to indicate whether ROIDS have been issued?
the nebb leaderboard hasn't been updated yet?
this issue doesn't resolved yet.
What does it mean if there is nothing next to my submitted task?
P.S. Just in case I sent it again (RPC)
Mean they are not review yet. Wait till they get reviewed
you may have to ping him (spork)
who was reviewd #480 ?
is it a joke ? his PR was rejected because actually the image not even work.
https://github.com/anoma/namada/pull/2477
https://github.com/anoma/namada/pull/2680
This PR already revert you can see old Docker image still use in main repo.
#630 extracly is copied idea
You can check #474 and #481.
if #474 is reviewed other submit the same is just copied.
They submit after that for week.
tag you here @frigid coral
how to submit s class task sir?
thanks! can't IBC checks be done based on indexed transactions? even if the network is halted
the genesis selection was purely about coordinating a stable network. we needed 100, and i think the vast majority came from previous testnet participants
idk what "poorly thought-out tables" means, can you pls expand?
lack of formatting standards seems like a big miss, imo. that's what led to lack of automation. also i think that not making the contest Sybil-resistant was a really big miss. what do you mean about the reward distribution? also technical difficulties **should **be considered, imo--the software should have been more stable.
hi @frigid coral can you please check my submissions? , Public RPC endpoint ht tps://rpc.namada.famnode.my.id/
tpknam1qz3eh8gfqgr2m44cfu3pg6sun4wgt75jwc8jvd85ax0wv24tfrrsc78gjet
thx