Author

Topic: Arity, Sentivate, Viat, & a developer Q&A with Thomas Marchi (Read 165 times)

legendary
Activity: 1820
Merit: 1092
~Full-Time Minter since 2016~
interesting, will check out your whitepaper
im always a bit leary of coins/tokens just appearing on exchanges as you never know about distro and such
Q&A's are usually interesting

Good Luck on your project! Smiley
copper member
Activity: 68
Merit: 20
Sentivate Hybrid Web & Blockchain
Thank you for the attention and checking us out!

https://sentivate.com

Hope you will join our Telegram and Discord if you are interested in our project!

https://github.com/sentivate/Sentivate-Network-White-Paper/blob/master/WhitePaper.md

We are trading live on https://idex.market/eth/sntvt
copper member
Activity: 68
Merit: 20
Sentivate Hybrid Web & Blockchain
jr. member
Activity: 58
Merit: 1
Very good article written by 3rd Party Source https://twitter.com/ShitcoinSherpa/status/1102990949674827776

Take a deep dive into Sentivate & the Universal web, compare code, and address security & privacy concerns with developer Thomas Marchi.

https://medium.com/@ShitcoinSherpa_14974/arity-sentivate-viat-and-a-developer-q-a-with-thomas-marchi-9f5fd8441a00

Quote
What is it?

In their own words, “Sentivate is a hybrid web built to be a viable & realistic replacement for the modern web.Designed to be faster, safer, & more scalable than any centralized web or decentralized web.”

On to the token…

SNTVT is an ERC-20 token that has been released as a placeholder for their eventual mainnet coin, VIAT. Once Viat launches, SNTVT tokens will be swapped for Viat in what is essentially a 1:1000 reverse-split , except in the fact that coin possession in no way implies ownership. This does change the token economics significantly, though, so I’ll try to break it down as best I can.


The max supply of SNTVT is 4.2 billion tokens. So the total supply of Viat will be 4.2 million. Of course, everything else will also drop in relation to that — meaning Team & Adviser funds, currently totalling 1,050,000,000 SNTVT will then be 1,050,000 Viat.

All team & adviser funds are currently locked, and in all likelihood will not be released until after the Viat swap. I believe a vesting schedule is being discussed, although the current tax climate can complicate matters when you’re discussing a vesting cliff & long-term holding of a cryptocurrency. In addition, one of the advisers didn’t want to receive compensation, and so the team is looking to donate his portion to charity.

On to dev activity…

This review is a bit different from my previous ones. As my writing & review style gradually evolve, I try to think of new things that might add depth to these reviews. For this review, I’m examining dev activity versus another project in the space that claims to be solving some of the same problems, but in completely different ways. I also got a chance to address some of my initial concerns with dev/co-founder, Thomas Marchi. But we’ll get to that a bit later on.

For this comparison, I picked Nexus Earth because it’s a project I had glanced at before, and knew had been active in the space for quite a while. I also had a suspicion that it was either the overly-ambitious fantasy of a potential lunatic, or possibly something shadier. Regardless, I wanted to let the work speak for itself.

Now, if you’re looking strictly at commits, it almost seems like Nexus is really banging it out when compared to Sentivate. But Sentivate generally pushes out a handful of big commits at one time, while Nexus releases a flurry of small commits pretty regularly.

And this gets to why I really like it when projects are listed on Santiment . They make it easy to visualize dev activity, but unlike other Github analyzers, they remove worthless & forked commits from the equation — giving you a much clearer picture of actual work done.


A visual on dev activity is sometimes really helpful. Ask me about their social engagement trendline, sometime
I’d really like to see Sentivate added to their charted assets, but this time I have an actual developer (Sentivate’s Tom) I can consult on commits & code, and I’ll try to include links to resources backing up his statements. So that should give us a much clearer picture of what’s going on in the Github. Here’s a few of the problems he found, as he reviewed Nexus’ code.

Tom:
The developer clearly is still in the early stages.
Why is he still using var instead of const or let, still has empty spaces, still not using classes, poorly-structured project files, doesn’t use eslint with a robust style guide and rule set, doesn’t use async/await, uses new language feature words like async as variable names, not using spread, not using rest, over use of _ as starting character in variable, doesn’t use default parameters, uses the arguments object, no arrow functions, no async functions, doesn’t use Reflect, doesn’t properly loop through object properties, doesn’t make use of any short hand, doesn’t understand the event loop, some variables are named poorly, has race conditions, and doesn’t use template strings. That’s just to name a few issues that pop out at me.
Tom was also kind enough to provide a side-by-side comparison of code style & quality, shown below:


The left side is a sample from Sentivate, while the right is a sample from Nexus.
At this point I realized that there wasn’t enough time left before the sun burns out for Tom to tell me every problem that existed in Nexus’ code. Though, I’d wager he’ll be more than happy to try, if you ask him to. I still think it helps paint a pretty clear picture about the nature of “web 3.0” projects in cryptocurrency.

People paid an unconscionable amount of money for a project that is still delivering terrible code after previous valuation at a $100+mil market cap. This is one of the biggest issues in cryptocurrency, and one of the main reasons I’m trying to up my game as it pertains to reviewing fundamentals.

Special thanks to Tom for taking the time to go over that with me, a bit. It was very enlightening.

On to the team…

A relatively minor pet peeve of mine is team pages not having team members’ LinkedIn pages linked, along with a short bio, but that’s more a matter of making things convenient for traders attempting due diligence than anything else.

That being said, I think one of the quickest ways to demonstrate transparency is by making due diligence easier to perform. Moving on…

Thomas Marchi (Co-founder & Developer)

Tom has been building websites, designs, and mobile apps for local businesses since the eighth grade. In his senior year of high school, he started building an experimental social network (LNKit). He went to college for a short time at NJIT, but quickly realized that the courses were aimed at pumping out entry-level developers, and he already had working apps & paying clients.

Which, honestly, makes perfect sense. You don’t have the patience to train at Arby’s when you already cook like Gordon Ramsay. I’ll let his Github repos speak for themselves as a reference to his education.

Matt Karasiewicz (Co-founder/Finance)

Matt has earned a Bachelor of Finance in Entrepreneurship & Entrepreneurial Studies from Rider University. After University he was a managing partner at Menrvah , and the president of KMA Satellite Inc. , in addition to helping found & secure finance for Arity.

Lew Knopp (Co-founder)

Lew seems like a really interesting guy. Former Navy Seal, founder of Templar Titan Inc. , and Co-founder of the Center for Online Justice. His story is told best on his profile at TT’s website, so click the previous link if you’d like to dig deeper.

For the sake of brevity & review length considerations, I’ll say that they have some highly qualified advisers, and the focus on development is abundantly clear when you examine the makeup of their relatively small team.


When a team is creating something this substantial, I absolutely expect to see this many devs.
At this point I’ll move on to my newest endeavor, a Q&A session with Thomas Marchi. I really enjoyed having the opportunity to (hopefully) improve my reviews by directly addressing my biggest concerns with the developer. I hope that you find that it adds depth to my review, and please let me know in the comments or on Twitter (@ShitcoinSherpa) if you have any thoughts about it.

Q&A with Thomas Marchi, (Co-founder & Developer)
Sherpa: “What security challenges is your team having to address with extending UDP, and protecting from replay attacks, amplification attacks, and other potential vulnerabilities with UDP & 0-RTT?”
Tom: “Excellent question. Most of these issues are actually answered in part by the research done by Minimalt . As we have noted in the many comments on Twitter and our BTC Talk thread, we took our basic inspiration for the protocol and additional DNS functionality from Minimalt.
Packet security & integrity is solved with an AEAD encryption algorithm called xChaCha20. This ensures non-encrypted data in the packet is authentic while keeping the important bits
Private. To setup the initial handshake we used this specific Libsodium API.
This is basically the current standard for setting up an encrypted connection. If a quantum computer implemented Shor’s algorithm, (which solves the discrete logarithm problem in polynomial time), it could brute force widely used elliptical curve cryptography like RSA. We will address quantum computing when it’s realistic to do so. We’ll most likely opt for pushing Supersingular Elliptic Curve Isogeny cryptography into the stack, when it’s reasonable to do so.
We have our eyes on SIDH in particular. It shows fantastic potential for small keys which is a huge concern, as if you can’t get that key into a single packet it’s worthless for data transport protocols. Since packets are only encrypted with xChaCha20 (specific version we use), Shor’s algorithm doesn’t play a part there.
Many attacks are negated by the design of the protocol and of our Domain Information System; Sentivate’s version of DNS. Our DIS utilizes UDSP which is encrypted by default and is mandatory. Think of this as DNSSec built-in.
Replay attacks
In this context it would need to be a man in the middle attack where a person has access to said individuals’ network and can see packets.
TLDR — encryption process, xChaCha20, nonce, timestamps, puzzles, padding, identity certificates, and reactive security.
Replay attacks are automatically negated by the connection encryption process & xChaCha; each message has a unique nonce in which the old one could not be used again & any attempt to do so would automatically result in a red flag. The nonce is factored into the actual encryption process, and thus is mandatory.
During connection handshake it expects this from a single IP, preferably IPv6. In order for someone to send a request from a new IP address (if it’s a remote man in the middle) they would have to have control of the victims keypair(s). Although this security is optional, one could also take advantage of the time stamp data sent with the initial handshake packet. When this time stamp is received it can estimate response time between packets. This in and of itself is useful for spotting a man in the middle attack of sorts.
Amplification attacks
Oddly enough, this is a relatively simple solution, well-documented in both Minimalt, QUIC, and other modern protocols. The trick here is always to raise the cost of an attack or make it nearly impossible to pull off. I view it all from a resource or monetary perspective.
An easy way to handle an amplification attack is to ensure the first packet for the handshake is more than the amount of data sent back. For example, you can introduce padding to be mandatory on the first packet for a service like our DIS. Which means that it’s more expensive to send out the requests on their part than it is on our part to respond to it.
Another way to combat this from our DIS, is from the use of puzzles. For us, a puzzle can be as simple as a hashcash, Dynamic Proof of work, or humanitarian computational work (protein folding) that could yield Viat for both the solver and the DIS. So, if the DIS receives an insane amount of requests from an IP, it can respond with a puzzle.
There are multiple designs that will be up to the DIS/Service to implement or utilize. Since this entire process costs more time, resources, and requires a puzzle to be included for the resending of the handshake, amplification attacks are severally minimized.
Minimalt puts it elegantly:
“Amplification attacks against third parties: At tunnel establishment, MinimaLT may respond to packets from clients which spoof another host’s IP address. This is always the case with the directory service, which initially must react to a request from an unknown party before transitioning to PFS-safe authorization.
A MitM could spoof the source of packets, even while completing a puzzle interrogation. A weaker attacker could elicit a response to the first packet sent to a server. Given this, MinimaLT is designed to minimize amplification attacks, in which a request is smaller than its reply (to a spoofed source address). A connection request causes a connection acknowledgment or puzzle interrogation; both responses are smaller than the request.”
0-RTT
0-RTT on the Sentivate network functions differently than how it’s works on TLS 1.3. In TLS 1.3, a user has to have visited a site prior to even be able to do a 0-RTT handshake. Sentivate doesn’t have this fault; instead everything starts with the DIS.
0-RTT for us starts with our Domain Information System. The DIS returns a solid chunk of information. In addition to routing information, it also includes the certificates for the origin domain, among other optional details. Fun fact: we incorporate geo-location based routing support for our DIS — great for folks in different locations and essentially a front-line load balancer for services.
Reactive Security Identity certificates can be logged and shared by the services on the network. Imagine a network wide naughty list, so other services can automatically block known bad actors.
Sherpa: “What improvements have been made to UDSP over UDP?”
Tom: “UDSP is a reliable, low-latency, adaptable, bi-directional, real-time stream that’s encrypted by default. It’s inspired by Minimalt and Websockets. Although QUIC provided some research-based insight, UDSP took no inspiration from it.
The whole idea of shoving HTTP into QUIC packets I fear may have drastically killed the potential that QUIC could have had. From what I can tell, it looks like QUIC developers may have taken a thing or two from Minimalt, but that could just be coincidence. I used websockets to prototype the initial designs years ago, without even knowing it at the time.
UDSP can stream as many assets as required, out of order, at different times, and from different locations, while receiving real-time app data, and all over the same UDSP instance. A server and client can send messages back and forth and keep the connection open for as long as they like, or close right after the needed assets have been transferred. UDSP was specifically designed with the modern web, modern features, machine-to-machine communication, and the age of IoT in mind.
For example, if you loaded up Binance, first off all its static assets would be streamed to you over a single UDSP connection, and only the assets you required at that specific moment. The UDSP stream remains open and real-time trading data would be sent over it.
Let’s say you click the trading tab. Assets specifically for that view are streamed on the fly to you, and the GUI is built on the fly. Similar to single page web apps; but on a TAAR1 agonist with a slight hint of a 5HT2A/1A agonist. Everything is done over the same UDSP stream; there is no need to spin up additional for the same origin. We are experimenting with multiple tabs also being able to utilize one UDSP stream with specific optimizations enabled.”
Sherpa: “How do you protect against spoofing? Is it a more traditional handshake between two clients, or is there room for middleman attacks that you’re having to anticipate & protect against?”
Tom: “You would require the other user’s ephemeral certificates, and possibly the master signing certificate to spoof another user. However, like I stated before, there are additional counter-measures for that.
Sentivate’s Identity Certificates are actually two keypairs by default. A master certificate, which contains a keypair only used for signing and is signed by the Identity Registrar. The other default certificate is ephemeral and is used for the UDSP handshake. Your ephemeral certificate is signed by the Master and a print is given by the Identity Registrar.
There are also additional experimental time-based signing we have been prototyping that would force certificates that are ephemeral to be signed often. This would allow services to also treat identity certificates like tickets for network access.
What’s great about Identity Certificates is that they can always be changed and you can always upgrade your cryptographic settings. For the layman, Identity Certificates are presented like profiles in the browser and the setup process is painless and largely automatic.
The security measures you can take with ICs are very interesting. First off, say goodbye to ever needing to remember a username or password again. Say goodbye to password brute forcing, and hello to strong cryptographic primitives that keep you and your data safe. Leave your master certificate at home while you take your ephemeral certificates on the go.
You can even get more specific: leave your banking profile at home while you take your social media profiles on the go. To most folks, Identity Certificates will simply look like profiles. You can have multiple ephemeral certificates/profiles signed by the same master certificate. The security on Sentivate is extremely robust and goes well beyond anything the modern web could offer.
Sentivate can do all of this while being faster and lighter. Imagine all the data that’s associated with a typical login for the modern web to Twitter. First you have to establish an encrypted connection over HTTP via TLS. Then you need to input your username and password, and then send a request with those credentials. Then the back-end service has to validate them and respond to you with cookies. These cookies are constant credentials you carry and have to send over for each request.
Now Imagine this: You have this ephemeral certificate that establishes a 0-RTT connection and at the same time logs you into Twitter. Welcome to the future of web technology, Sentivate; the Universal Web.
What is used to identify you is a unique random ID that allows the service to manage your connection and assign credentials to the stream. For those wondering; yes, that means you can send real-time messages to the same user that’s on multiple devices even if you have the connections on different servers or locations.
Those familiar with the back-end of RethinkDBs change feeds and websockets will feel like they walked into the gates of Heaven.
Hardware-Based Security
We would like to combat IP fraud and hacking with hardware specific solutions, dubbed, “NID & PSBs”. It would be the only true way to bring law, order, and accountability to the wild wild west we call the interwebs. However, that will remain proprietary for now. Network/Internet Service providers: hit us up if you want to fix the web. Yes, they sit on the network. No, they are not local or accessible to clients. Think of police for web traffic.”
Sherpa: “If adoption did happen, what possible limitations does the domain name system have? It seems like the rules would eventually lead to a clowpenis.fart scenario.”
Tom: “Actually, we have totally different domain rules and are extremely annoyed with things like domain-squatting and the lack of domain categorization. We have a long list of regulations that protect against this type of downright predatory behavior. There is no “parking” allowed, blatant misuse, or pretending to utilize a domain like GoDaddy and others do.
There are always exceptions but that is only related to trademark usage and personal legal names. We hate this domain abuse practice because it destroys the market and limits growth.
Without going into too much detail, any such attempts would result in a Viat-based fine, the loss of the domain, and potentially the loss of other owned domains. There will be an entire report process for this. The only time where holding is acceptable is during our Shopkeeper expansion, with exceptions. During the network launch, these rules and regulations will be made available to al,l and a grace period will follow.
We fully recognize US Trademark law, but we also recognize that there are predatory trademark practices that go on against the little guy.
Another concern is proper categorization of the web. We hate ICANN. We hate their clear lack of evolutionary concern for the web, and we hate that the US signed its control of it over to chaos.
On Sentivate, if you want to run an e-commerce store, well you have to get a .store domain. If you want to run a legit news source, you best be using .news — if you want to run a social network, it best be on a .social domain extension. There is no .com, but if it is used the Sentivate browser will treat it as a shorthand for .company, and then send it to the DIS to process your request.
Examples:
Google.search
Facebook.social
Newegg.store
Fox.news
UnitedStates.government (Reserved for Gov)
government.us (Reserved for Gov bodies of US)
naughty.porn
IBM.company
NTT.network
bitcoin.cryptocurrency
ethereum.decentralized
libsodium.cryptography
Dota.game
LeagueOfLegends.game
The domain system for us is all about equal opportunity, preventing abuse, providing startups with a variety of naming conventions, anti-domain squatting, organizing the web, eliminating spam, and protecting trademarks while at the same time protecting the little guy.
This will also have an effect on search engines’ practices that prioritize certain extensions. A very silly practice in terms of the web, but it’s done to filter out potential spam on the current web. However, on Sentivate that’s no longer a problem because domains are to be organized according to their service and information.”
Sherpa: “Do you have any concerns about privacy? How are you protecting users’ privacy with a static, undeniable identity? That feels like it could be a problem; almost an extension of the Chinese social reputation system.”
Tom: “Oh, it’s actually the exact opposite of a problem; it’s the solution. Here’s how:
Identity certificates are ephemeral in nature and consist of a keypair and additional typical data, some of which is optional. This ephemeral certificate is signed by a master certificate which isn’t shared unless explicitly asked for and permission is given to the service or wallet transaction.
This identity certificate is your cryptographic Identity which can be changed at any time of your choosing, hence them being ephemeral. Only you know the person behind that certificate and anyone else you tell it to. As far as anyone else knows it’s just a unique cryptographic keypair.
However, if you provide personal details to a service then you are asserting that yes, that is you.
We will accept legal names on certificates to allow for things like democratic voting. There is a procedure for that which we plan on first implementing in the United States. Users would initially
require manual review and processing to have their IRL identity cryptographically linked to an identity certificate and in effect linked to a certificate blockchain. This would be useful for businesses or sellers looking to authenticate to services and buyers that their IRL identity is linked to an Identity Certificate which acts as a wallet address for Viat.”
Sherpa: “How is this project different from other crypto ‘web 3.0’ plays?”
Tom: “I love this one. Web 3.0 is nothing more than a bunch of scam projects with lofty, unreachable, unrealistic goals. A solely decentralized web will never replace the web we have today. It’s downright ludicrous and deceitful to ever suggest such a thing, if the only goal is to replace the existing web.
All of the projects who think they are going to replace the web we have today with a solely decentralized network need to put down the peace pipe, stop taking hard-earned money from folks, and for some — stop pushing your ideology on others in the process.
All this “web 3.0” and “blockchain 4.0” talk is nothing short of buzzwords and hot topic marketing jazz. Anyone with a background in network topologies and protocol development knows that such projects are utterly unrealistic.
Our view for Sentivate is to make a web that is realistic and viable, which can replace the web we have today. Sentivate in every sense of the word has to be faster, more reliable, more secure, more private, cheaper, and do a whole lot more with a whole lot less. It can’t perform just as good. It has to be better in every way, and then some. Sentivate’s web is centralized-focused, but enhanced by its decentralized systems. This is why it has a hybrid topology; so it can actually do what we set out to do.
Developers are concerned with ‘How can I get my users these static assets in less than 300ms?’
Not seconds, not minutes, and not hours.
Decentralized networks create slower apps that offset costs to users. Users have no business paying for the cost associated with Facebook’s infrastructure.
Users like those on Binance need to be able to send real-time instant trades to Binance’s servers, which are instantly verified and matched if there is such an order. All of that happens in ms, not seconds.
Adopting a fully decentralized web would bring our economy to a dramatic halt. It would crash the world economy, it would crash industries, and it will end up killing people in the process. It’s not just a pipe dream; it’s an absurd network design for the web.
I get a kick out of it any time I see these “web 3.0” projects saying they offer real-time updates.
What an absolute joke. Yeah, you pay for a transaction. Then it has to get verified, and then it has to be accepted into the blockchain, and then it propagates to nodes, and that’s when they start ‘counting’ the time in their ‘real-time’.
In the reality where we live, real-time starts when the user clicks the mouse. It shoots directly to the service, users are instantly notified over a websocket connection, and all of that is done in milliseconds.
We don’t see “web 3.0” networks as competitors because they are nothing short of charlatans, weekend developers, or at worst ideologues. We typically see projects sponsored by or led by folks who say things that are either communistic, socialistic, or the usual line “post capitalist system” “reasons” to have the web solely decentralized.
When you try to play god with networks, and inject morality and ethics into them, the result is a poor design and a slow network. When you try to enforce things like that idealistically with blinders on, you end up with people dying. Folks typically don’t realize that the whole decentralization push and open source push was typically involved with a political movement.
Bitcoin and Ethereum were so successful because they focused on implementation and realistic goals, and within a context.
Viat
Now here’s where we take a different approach to network topology when considering Viat.
Viat is the cryptocurrency we are building on top of Sentivate. Viat is decentralized-focused, but enhanced by centralized components. Again, this is the opposite balance to Sentivate’s web, and for good reason. In the realm of cryptocurrency, a decentralized topology is the most rational.
Centralized systems can supercharge aspects of Viat like wallet security, instant transactions, and dedicated transaction verification for the network. The opt-in centralized features, like wallet security allow your funds to be frozen in case of attempted theft. For us it’s all opt-in. You are free to choose your own path, how you wish. Forge your own way on Sentivate and Viat and operate the free market just like in capitalism.
You are free to make your own mistakes or bowl with the bumpers turned on.”
Sherpa: “Do you see UDSP as eventually becoming the standard, or are you more interested in smaller, permissioned spaces — I know the whitepaper specifically mentioned elections & gov’t applications.”
Tom: “UDSP is just an aspect of Sentivate. The entire network as a whole is what we are pushing for the adoption of, as it’s a full package.
We have actually seen changes like this happen in secret already. QUIC has been quietly installed in Google browsers and Google services. Every time Chrome contacts a Google service it makes use of QUIC. IETF saw the efficiency of QUIC, and now they have adopted it into HTTP3. Which only further proves that what we are building isn’t just viable and logical but highly required for the future state of the web.
The point is, moves like this can happen and it can be very easy for the user. Chrome could also support the Universal Web and then users could access both the old World Wide Web and the new Universal Web. That’s exactly what we will be doing with our browser. It’s a stripped down version of the Chrome browser with several front and back-end enhancements. The Viat wallet and profiles can all be done from what everyone would see as a well-designed ordinary beautiful browser.
Let’s talk numbers…
From a business standpoint, stats from Amazon highlight the issue. Every 100ms of delay, Amazon loses 1% of profit, which is in the millions. Every 1 second of page delay for the year costs over 1 billion. Companies have too much to gain not to push for such a switch. The longer they use outdated web technologies like DNS, HTTP, TLS, and yes that still includes HTTP3.”
Sherpa: “I see that this iteration of your whitepaper came out five or six months ago. I know it references the puzzles being explained more in version 2.0 of the wp. Is this essentially a captcha, or more an algorithmic thing that is done ‘under the hood’?”
Tom: “Yes and no. By default it actually ties into Viat’s Dynamic Proof of work system. However, the service can choose how it distributes puzzles and in what form. It would be in the service’s interest and be far more efficient to use Viat’s dynamic proof of work centralized system to serve them out.”
Sherpa: “I didn’t see a whole lot of talk about revenue models. How well is the project funded now, in terms of runway? And how will the project fund itself moving forward?”
Tom: “We are focused more on securing long-term clients utilizing this technology. It’s important to stress Sentivate is a product and Arity (Arity.company) is the parent company. Arity is perusing contracts which incorporate Sentivate in some way, shape, or form. However, we can’t officially comment on that at this time.
Sentivate will always be directly funded by Arity. We have been filed since 2014 and we have a long history of all sorts of activity. We will also be bringing in our profitable apps which have already experienced success, like Hermes (a social media automation tool) onto the Sentivate Network.
Viat has a very interesting economy attached to it inspired by Ayn Rand, Milton Friedman, and Yaron Brook. A topic for another day, though for the sake of time, we can discuss this more in depth in a follow up.”
Sherpa: “Who do you see yourself needing to market to most? End-users, developers, or businesses? Do you have anyone specifically tasked with B2B sales & developer relations?”
Tom: “This is in large part already handled. We don’t expect to be having any issues in that regard. If every single thing fell through from funding, to B2B contracts; you name it. We still have apps that we’ve already tested in markets which have vast holes that only new technology can solve. These apps will only be released and capable of running efficiently on the Sentivate network. Matt has shown great interest in building a crypto-focused exchange using the technology. Nonetheless, that would require a lot of legal guidance at its current state.
In terms of a marketing team, we have been growing that out. We are here to BUIDL just like we have been doing for years. Longer than a majority of crypto projects, and focusing on business sustainability outside of token economics.
We understand longevity and what it means to look 5 to 10 years down the road. In this space, many of these players are looking to be out in 6–12 months. Blockchain has disrupted many industries in the financial sector. It’s about time we disrupt blockchain and decentralization with some cold, hard reality.”
Summary: In conclusion, I think the Q&A really helped me answer some concerns I had, as someone lacking any experience with coding & some of the more technical aspects of this project.

I’m honestly having trouble finding any glaring issues, other than a few small critiques about making their team page & profiles more accessible. The team & advisers’ share of tokens is a bit higher than I’d suggest, but already a portion of that is being earmarked for charity.

All said, I couldn’t be more interested to see how this project develops, and if they can find adoption. They’re looking to solve myriad problems our outdated Internet infrastructure has, and in some unique & potentially brilliant ways.
Jump to: