I am working on a Web3 project that taps into NFTs and PvP mechanics, with the potential to go viral. The concept is unique and hasn't been seen before. It will be launched on the Base chain.
Am looking for the following people:
* Front-end developer to help build out the interface
* Social media operator to build hype on socials and manage the Discord
I built and launched a v1 prototype of the project [0], and am taking the lessons from that to launch a much improved v2 that will (hopefully) be more viral.
> I built Mailmask in response to the frustrations of having to deal with spam, email addresses being sold to advertisers, and being unable to unsubscribe from or block certain senders.
Couldnt have said it better myself, its the exact same reason i built my own too.
We will definitely experiment with Swarm once it's out and see how well it fits with our needs. This document covers some of the differences between swarm & IPFS for those interested: https://github.com/ethersphere/go-ethereum/wiki/IPFS-&-SWARM
For the MVP we will gift a bit of ETH to each user that installs AKASHA and creates a profile. We are talking about enough ETH to enable an average user to publish, comment and vote for a few good days. The "perfect" amount will most likely be determined after observing how real users interact with the application during the alpha. If along the way the user will generate content or comments that will in turn generate upvotes he will refill/increase his ETH balance.
It's important to note that users will be able to read entries and comments without needing any ETH so access to information is free in this regard. ETH is required only when you want to interact with the dapp living on the Ethereum network.
In any case, from my rough calculations, the costs involved in publishing an entry with 1 tag would be recovered after receiving 1 upvote. All the upvotes beyond that point would be profits going to the author.
We are also open to experimenting with things that might enable us to take over some of the interaction costs at the smart contract architecture level, but that is outside the scope of the MVP.
As for the business model we don't like ads in general so we want to experiment as much as possible on this side as well to see if we can co-create a sustainable social media network model that does not rely on ads to survive.
We don't know yet if that model means a custom token, a micro-fees scheme or something completely different that we can't even imagine at this point so we chose focus first on building the dapp and learn from the actual usage what direction we should take.
Full-stack Javascript developer from the UK currently based in Taiwan. Am a fast learner and can effectively work in a team and/or take the lead on a project. Contribute regularly to open source.
Hi! I'm a polyglot developer from the UK currently based in Taiwan. I've worked with various languages and platforms, all the way from J2SE/J2ME through to Drupal, Django and most recently Express, Angular and React. I'm a fast learner and can effectively work in a team and/or take the lead on a project. I contribute regularly to open source projects and have a few popular NPM modules.
This is just a mini project I decided to do in order to learn how to use Electron.js to build desktop apps, plus the fact that I wanted a diary that did encryption properly.
Right now there's just an OS X build (because that's what my machine runs) but it shouldn't be too hard to get Linux and Windows builds going too in the near future. Also, the diary features are a bit limited (e.g. not date changer yet).
I'm trying to move away from using Bower and just stick with NPM, but that's purely to simplify my project setup. I'd rather have one package manager managing all my dependencies.
Good work. Though I have to say I've seen so many of these web-based "secure, private, anonymous" chat services now, I've lost track.
What we need is end-to-end encryption and with an open source client that just has to be downloaded and built/installed once (and in such a way that it's verifiably secure, think reproducible builds).
Author here. This is meant to be something super simple and instantly accessible. Start and finish a conversation in mere seconds if need be with no traces.
I am sure downloaded clients with end to end encryptions exist, but it's definitely outside the scope of something as simple as Niltalk.
why does the client need to be built locally? Are you inherently suspicious of anything delivered over HTTPS?
I'm genuinely interested in why people feel local clients are more secure than something running in a browser. It's something I came across when writing an ssh client in browser (www.minaterm.com).
I guess it's the potential for a HTML page to updated overtime so it no longer reflects an audited version. However it seems that it's really a failing in our browsers that this is the case. Perhaps an external service that verifies the hash of a page would help? But this would need browser support of course.
The only thing I could think of that could be implemented in current browsers was a small stub page which calculates and displays a hash of the HTML/Javascript to be launched. The stub would need to be small enough that a user could manually check that nothing malicious has been added here.
"why does the client need to be built locally? Are you inherently suspicious of anything delivered over HTTPS?"
A good question.
In order to have end-to-end security, you need some sort of secret that is only known on the end points (possibly negotiated over some sort of key exchange protocol), and it should be impossible for the server in the middle to have the secrets.
The core problem is that a webpage is really, really, really designed to be a representation of the server, sitting on a client sandbox. There is no built-in way for a web browser to inject anything into the connection that could be used for a security connection in such a way that the server can't see it. All the local storage the page has access to, the server has access to. All the cookie data the page has access to, the server has access to. Anything else you can come up with that the page has access to, the server can either read or destructively set by sending down the correct HTTP or HTML. There's no independent client "context" that can be passively, safely used by the page somehow, and in a world where the page is running javascript provided by the server it's not even particularly clear what could be "used" by the page without being something that the server could "use" by reading, then sending to the server.
There is, therefore, no way to use the web through a conventional browser to create an end-to-end connection that the server doesn't have full access to. Browsers just aren't designed for this use case.
Note nothing stops you from providing an HTTPS REST interface that would allow full end-to-end encryption that is used by a client that is capable of having local secrets and does not provide any way for a server to run code against it. It is specifically the browsers making this impossible. I'd also observe this isn't necessarily fundamental, browsers could be changed to fix this, but... I'm not sure it would be a good idea. Browsers are already insanely complicated security environments that just barely work on the best of days. Not sure I want to add "secure-from-the-server secret storage" to the list of things a browser is supposed to be able to do. (It is also possible certain extensions in the browser have already hacked together this ability, such as the video chat extensions, I haven't studied them to that detail, but AFAIK secure secret storage and key negotiation aren't generically and generally available.)
1) Don't really care about privacy. Might not want their chat on the front page of the papers, but aren't going to go to great lengths to achieve that.
2) Actually care about privacy and are informed. There's not many of these people, but they're trained to be wary of every outside dependency and opportunity for hostile code injection. Crypto running in the browser can be replaced any time you load it if the host is compromised - either in the technical sense or the legal sense. Yes, it could be hashed, but it isn't and there's no mechanism for this nor plans to build one.
Not to mention that the browser itself presents a pretty large attack surface.
> That's kind of a shame. It would be nice if apps distributed over the web could be signed the same way they are from repositories.
This sounds like a theoretical impossibility. The server's source code is by nature closed, and while the server could provide you a copy of the source with a signature, there's really no way for you to verify that the code you've been promised is the code that is running.
A browser feature would be required that could calculate/display the hash of the delivered code and optionally verify it against a 3rd party server. Ideally you'd want have particular versions signed as "audited" etc.
You're neglecting the server-side code. If you have access to the full source code to verify it, you're not describing a web service, you're describing a local application that happens to be implemented in a browser.
You already can distribute signed browser add-ons.
I was looking for something like minaterm the other day, trouble is i'd be scared to put my credentials into it. A when I think about it logically that isn't rational (putty can grab my credentials just as easily), but still.
It's not entirely irrational. If putty wants to grab your credentials they have to ship a broken binary that once downloaded exists forever and can be examined and reverse engineered in the wild. Someone running a web service (or someone who has compromised said service) can target a particular user for a single session and the evidence that an attack occurred will only exist until a few caches get cleared.
yes, and I also would be scared to too. It's interesting thinking about why though. I think there's a significant social/psychological component to the decision.
I'd also be less scared if it was running on my own server, but it's not clear to me that this is completely logical either.
If the code can't change, what's the point of having it be delivered through the browser each time? Aren't you better off saving the bandwidth by downloading it once?
That's true, but given the gradual shift to ES6 features over time you're more likely to end up using something like Bluebird (e.g. to complement your generators) and so having another library to then handle asynchronicity (and that too with callbacks) would be redundant.
SEEKING WORK: Remote (from the UK, currently in Taiwan)
I am a full-stack web developer with 9+ years experience backed by a Computer Science degree from Imperial College London. I mainly work with Javascript/Node.js (as well as Angular, Ember, Bootstrap). I also have some experience doing continuous deployment setups (using Docker, Jenkins, Drone, etc). In the past I've worked in C++, Java, PHP and Python - I can quickly pick up new technologies and tools as and when needed.
I am working on a Web3 project that taps into NFTs and PvP mechanics, with the potential to go viral. The concept is unique and hasn't been seen before. It will be launched on the Base chain.
Am looking for the following people:
* Front-end developer to help build out the interface * Social media operator to build hype on socials and manage the Discord
I built and launched a v1 prototype of the project [0], and am taking the lessons from that to launch a much improved v2 that will (hopefully) be more viral.
To apply, email: team [at] v42 [dot] space
[0] https://jigzaw.xyz