https://snap.berkeley.edu/snap/snap.html#present:Username=18001767679&ProjectName=netbloxx
Will work on improvements after supper(Port to snap | NetsBlox)
Wow!I might improve this after school
https://snap.berkeley.edu/snap/snap.html#present:Username=d4s_over_dt4&ProjectName=netbloxx
There you go with the async thingy
Whaa?What?You did it?
I was still struggling over the promises and the asyncs and the process.prototype.pushcontext.doyield something
Had to retake the entire javascript es6 tutorial
PS:You still have hard coded project ids or usernames and if you really want to use it your self,pls do not do that under my netblox account 
Hehehehehehe...
Oh okie ill do some changes
The complecated part is to make everyone have a netblox account AND a netblox project AND to make them change the block and refer to their project 
Edit:this does not have to be real so it simple
It works without a username,t or role,but it needs (is some random thingy)uuid and (is some random thingy with the location.hash)projectid to work
Turns out that netblox only does a presence/absence test,not a validability or authenicathy test loooool
PS:We realllllly want username blocks,@jens,could you pls revoke the ban or add a block that needs something like process.prototype.enableUsername to work?
it can be just like the js function and tells you that the project seeks for private info and lets you decide whether its important to keep the username(and read the code looking for a phishing problem)
or you could just add some alert to js enable prompt like "this also enables username peeking so dont turn it on if you seek the code and find something thats transmitting your private info away"
Jens is a bit very concerned about security and he probably wont accept that feature request 
We already have this block in the getter/setter library, i think you can use it without be banning (in doubt, ask BH). You just need to enable js before...(your block already use js, so no problem here...)
no, that value is stored when the snap session loads then never touches the api when calling it.
Didn't jens say that using ide.cloud would result in a ban? Since that block looks at a child/property/value/whatever of ide.cloud, I think it's not kosher.
I heard in another topic the value was stored on startup.
Oh. I have no idea.
I don't think Jens will ban you if you use a block from a built in library from Snap; It's a non-sence...
Final thing on this topic (from me at least, I don't really like talking about it)- I don't think it's Jens who actually does the banning, I'm pretty sure it's automatic. That's why it's not great.
Nope you can't.no disinguishing between naughty access and normal access
its automatic
how do you know that and how would it even be able to automatically ban people
what d4s said makes sense to me here