Uranus Code Review: Ubiquitous Sharing Platform
Share this article
Going to be difficult to keep this Uranus code review professional. So this week I have looked at Saturn, Jupiter, and now Uranus. I’m not joking. I’m not making this up. Looking for guidance on what they do, website features Uranus, giant and throbbing, on the front page. Primordial God of the Sky delivering light and power to every corner of the world, it says… again, not making this up.
Mission is to ’empower the redundant computing power of the world’ (empower?) but as soon as I see ‘aims to be the Airbnb and Uber for computing resources’ I start feeling hopeless.
Ok, well, since we’re all here let’s deep dive into Uranus. Yes, this article is going to be filled with these. Yes, I’m 12 years old.
Skipping the whitepaper since it doesn’t have any real technical content, instead let’s see what they have so far.
We have a tendermint fork, a kubernetes fork, and a runtime fork. So ignoring those 3 for now. Then we have UraEP (C++), UraEngine (Java), UraAuth (Python), and UraAgent (Python).
Very little documentation, so we are going to have to do this the hard way.
UraAuth gives access to Uranus. Hehe. Ok, I’ll stop now.
Authentication system. Just backend and Flask (Python HTTP library), but let’s have a look.
It’s not often I see SQL scripts in the code, so this is actually a nice oppurtunity for me to talk about some SQL design choices. Data architecture is one of my passions so I take a lot of time and effort with the data modelling side of my designs.
So looking at the above, we see Tel (telephone number) as the primary key and we see it is defined as a bigint (30) with an additional btree index added on top.
- Maximum regional (with international code) number limit is 36 characters. So I recommend this to be 36 not 30.
- Primary key already creates a btree index, so the secondary index is redundant
- As a bigint you will lose the leading 0 and can’t differentiate between local or international numbers.
I have some other concerns, the data types for name/password/email are a bit lazy, just making them 255. And then the rest are more personal preference things, like table names should be plural, and stick to one naming scheme, here we have camel case, we have underscore notation, we have inconsistent capitalization. So probably just a rushed job.
I can spend quite a bit of time on this still (especially when starting to talk about foreign keys), but for now, let’s move on.
Constants declared and used. Good practice.
Very detailed comments and examples in the code. Documentation outside is sparse, but inside is fantastic.
Basic HTTP API for now, registration, login, checktel. API 101 stuff. Let’s move on. UraEP has some Client Server code, so let’s give it a quick look.
Not 100% sure what I’m looking at. CtepCommClient and AppChannel have most of the code.
Dynamic channels being created between client and server. Code is good, I just don’t know why it exists though.
Custom client server connectivity stuff. Let’s move on to UraAgent.
Using PAM for user authentication. Does local linux based authentication (don’t know why).
Guest-agent is just ovirt. So, it doesn’t really help we look at the code detail, let’s look at the commits.
No real changes here, so we can ignore UraAgent. Let’s go into the big repo, UraEngine.
14,867 commits, 1 branch, 84 contributors. 84 contributors and 1 branch.
Started in 2011. Safe to say this isn’t a blockchain project.
Nevermind, found the copy.
UraEngine is just Ovirt-engine. Let’s look at the commits.
What is cloud-times though?
Some cloud virtualization platform.
Talks about CTVP
Which is just Ovirt-Engine SPICE renamed.
Uranus Code Review Conclusion:
No clue what’s going on here. Just code copied and some renames. Not sure what the basic HTTP API, Ovirt Engine, and the C client/server have to do with each other, but nothing here yet.
No real detail in whitepaper. And what is happening in the github isn’t lining up with what they are promising. Doesn’t seem like there is something real here.
Disclaimer: Crypto Briefing code reviews are performed by auditing what is on display in the master branch of the repo’s made available. This was performed as an educational review and any comments in the article are the opinion of the writer. It is normal for code to change rapidly, hence we timestamp our code reviews so that they present a snapshot at a moment in time. Information contained herein should not be used as any comment or advice on the project as a whole.
Uranus Code Review Timestamp: June 22nd, 2018 at 12:17 GMT