Lein-droid author here. A few commenters asked about the performance and maturity of Clojure for Android, so I decided to answer in the top level.
The main problem of Clojure for Android right now is the large size of Clojure runtime. This leads to two issues:
a) long loading time (can take a few seconds even for the basic app),
b) applications often gets closed by the OS once switched to another, in order to free that memory.
Since ProGuard is no help in optimizing Clojure-compiled code, the issues should be addressed in some other way. One that is possible is to write source-shaking compiler that will strip the final APK of the unused functions. It's pretty hard to do with the current compiler, but if we eventually write Clojure-in-Clojure compiler (there is a proposal for this year's GSoC by the way), it may be feasible to add these optimizations to it.
Thanks very much. By the way, currently clicking the link in a browser doesn't seem to bring up the intent chooser to open it in the Nightweb app. I'll try to fix that today. In the meantime, the workaround is to email or text the link to yourself, and click it from there instead.
Yeah I've thought about allowing multiple users on a single device, so I'll look into that in the near future.
EDIT: I fixed the issue with clicking links in browsers. I will issue version 0.0.5 with this fix because I think it's pretty important.
you should define a separate namespace for users/posts, like a subdomain or path, for the app, right now the browser is confused when opening the homepage
But it would undermine the "distributedness". Maybe Nightweb could serve a website on the device itself and one could use pagekite or a dynamic dns to serve it.
First, the website would only be meant for users without the app, so local hosting would not work. Second, it can only be read-only, unless you upload your private key.
I think it would provide a window into the social network, kind of "Oscar is using this, join him now by downloading the app!"
The implication I see is privacy of people clicking a user link, but the problem already exists now.
There's no reason a third party couldn't host a read-only view into Nightweb, performing something similar to tor2web.org.
The third party would be running their own Nightweb client, then visitors to the website would trigger content downloads on the client, rendered out as a webpage.
This would provide the "public view" without sacrificing the decentralized nature.
However, Bittorrent is not up to the task, due to NAT issues. UDP NAT puncturing is not present in this stack, right? Thus how is it going through carrier-grade NATs which block all these smartphones?
Disclaimer: working on a similar thing for years Tribler Mobile.
I think it's considered bad practice to define your own URI scheme for your app, though it is very common on iOS since you have no other choice. I thought using HTTP links would be nice since (a) they are much more likely to be linkified when pasted in emails and on websites, and (b) clicking them from non-Android devices will take you to the website where you can learn about it.
You could also have a context header on top saying something like "Join [User] on Nightweb" or "Hey, [User] is on Nightweb!" and then your website follows explaining the concept.
Things have improved quite a bit recently. Daniel Solano Gomez is the pioneer here, and Alex Yakushev made it a lot simpler by creating the lein-droid plugin for leiningen last summer.
It will impose a few seconds of load time no matter what, so it is best for long-running apps where loading time isn't as important. The cost in runtime speed, memory consumption, and APK size are also present, but aren't a big issue in my experience. The same Clojure optimization rules apply.
I think things will get better and better once more people use Clojure to write Android apps. It will be a signal to the core devs that it's an important platform. Currently, you must use a fork of 1.5 that includes a few necessary modifications.
I've just tried NightWeb and the startup latency is very high, even on my Nexus 4. Sadly I can't think of an app where 5-10secs of latency is acceptable :(
If you manage to get a Clojure Android app to boot up quickly, I would be very interested. For now, the only reasonable ways to not use Java for Android apps that I've found are Scala or Xamarin.
While the app is interesting, I am also more interested in Clojure's feasibility for writing Android apps. Last time I looked, Dalvik's GC was so bad it took many seconds for the Clojure runtime to bootstrap.
There is also the possibility of using and wrapping the Apache Cordova (phonegap) API from ClojureScript. Trade-offs galore there, but one advantage is faster (still not comparable with native) startup time.
Just in case anyone has the same issue: on my device (Nexus 4) it took a while for the UI to become responsive when first opening the app. Patience solved this one :)
The word "decentralized" is a pretty loaded term unfortunately. I think tent.io and other similar projects are decentralized in the sense of who controls the servers, but they are still fundamentally client-server protocols. Nightweb (and I2P specifically, which it uses) is fully peer-to-peer, so there is no distinction between clients and servers. I think that's the most important difference.
Sorry about the non-responsive loading, I will work on that in the future.
Does this have a particularly adverse effect on phone battery life, when compared to a well-written app for a centralized social network (aka, not the Facebook Android app; perhaps the G+ app)? I can imagine that a lot of uploading of social network content to your peers would take place.
Also, what is the bandwidth utilization like compared to an app for a centralized network? With a lot of us on tiered data plans now, this is a crucial concern.
I ran the app for most of this morning on my Nexus 4, after adding most of the links in this HN post as favorites. Between 9 and 11 my battery lost 40% of its charge. Ordinary usage tends to yield 14 to 17 hours of battery life from a charge. This kind of impact on battery life will be a deal breaker for most people until resolved.
Spotify's desktop app is P2P, but their mobile app is server-client. Perhaps advanced users could mitigate the battery life issue in the short run by setting up a "proxy" on a server that joins I2P, while presenting the front-end on a mobile device -- like you would with, say, an IRC bouncer.
I own a Nexus 4 and agree with the parent poster. 14 or more hours mostly idle is normal. I get even more if I dim the screen for normal use.
Fortunately, Android JellyBean provides all the data you need to fix your problem. If you are getting worse battery life, you need to check Settings -> Battery and determine which apps are unreasonably eating up your battery life.
Android 4? That's a pity. But why a mobil app? Why not a .war app for the i2p router? IMO Social networks are something that are mostly used on desktop computers.
Also it seems to me like you want to fork i2p. I think that's a very bad idea. First since you should be very confident in your skills if you roll your own crypto. Second because a split seems not necessary and harmful in the long run for the network. The i2p networks could be bigger aswell, and this could help.
I didn't actually modify the core or router code at all, I only needed to modify the I2PSnark code (i.e. the BitTorrent component). I did not roll my own crypto at all, other than the digital signing of meta torrents which is an application-level concern. It is technically a fork because I have a separate copy of the I2P codebase in my repo, but I will always update it to the latest versions as they come out.
>but it will pay big dividends later if I need to rewrite parts of the I2P backend.
I'm all for clojure, open source, innovation and forking. But i urge you to stay part of i2p and not create incompatible releases. Maintaining your private branch will result in a lot of extra work, and I'm 100% sure that this will result unfixed security holes. The i2p project on the other hand would probably gladly accept your java patches.
Understood; I actually was moreso referring to rewriting I2PSnark, not I2P itself. The BitTorrent codebase is pretty old and I know I can improve it if I had time. I agree that touching the core/router code itself is dicey, but keep in mind the I2P developers themselves have encouraged people to make alternative implementations. I don't plan on that right now, though.
I think the I2P community would be thrilled about I2PSnark patches. I2PSnark is in active development currently, as the I2P update mechanism is being moved into I2PSnark.
I wonder how they're going to get around the problem of malicious collectives and Sybil attacks, given the anonymity constraint. You should be able to set up dozens of fake accounts to vouch that you're a "good" person, or that someone else is a "bad" person, use astroturf tactics to wage malicious campaigns against other parties, and basically sow havoc.
This app is pretty well polished and from an ideological standpoint very awesome.
If you have any feedback/requests for I2P, I'm sure that zzz would be very interested since he did all of the I2P@Android work. Catch him on zzz.i2p or #i2p-dev on the I2P irc net.
Yep I've spoken with him a few times on his forum. I announced Nightweb there a week ago but I don't think I ever got any replies. I am definitely willing to incorporate any changes he suggests, as he knows the I2P codebase as well as anyone.
Why do you say it's a "killer app" for Android? I think it's a great idea, but it does not use the fact that it lives on a mobile phone, so it's certainly not a killer app for it.
The main advantage of the application running on phones is that everybody has one (hyperbole intended) and that phones are always on.
For a web version to be fully distributed it would need to be run on a server, so people would have to hook up a RaspberryPi at home, rent a VPS or trust some big Nightweb farm (the diaspora model).
It's infinitely easier for most users to just install an app on their phone.
A Desktop version would probably not be "always on", which would limit the usability as a social platform seriously.
You have to find people externally, such as through the links people shared on this page. There is a bug preventing links in a browser from being openable in the app, but I just released an update that fixes this. There is no way to discovered people internally right now, though I did make it auto-add my user so you can at least see some content after it runs for a little while.
I don't think of it as "anonymous" networking, but more as a network that can't be controlled or brought down. Especially by relying on bluetooth and future, improved peer-to-peer connection technology, we could be free from carriers and ISPs.
I always had the idea to create a distributed social network, I'm looking forward to seeing how this goes :-) Hopefully very well, would love to delete my facebook account.
One thing that wasn't clear in the protocol or explanation page was the favorite-of-a-favorite discovery.
I'm assuming this works by including your personal favorites in your meta torrent, so when people get your new content, they also get a list of who you've favorited?
Does this also mean that the meta update notification gets sent out when I favorite / de-favorite someone?
Nice take on announce_meta, btw. I had mused over something similar (though not as well fleshed out) to the Nightweb concept but kept bumping my ahead against the notion of how to announce additional content when the bittorrent protocol ties info hashes (and magnet links) to a direct hash of the content - meaning you could never update something already announced for a specific key. And since the hashes are content based, it's not like you could say "my next content will be <<previous hash plus 1>>".
Extending the protocol to include a new announcement method side-steps this very nicely :) Kudos.
Ditto. Definitely seems like it has the potential to be the Killer app based on the viral potential of P2P, anonymity and widely adapted OS platform. All the best.
I am definitely considering making a desktop client. I can re-use all the backend code but will have to make a UI from scratch, so it won't necessarily be soon.
Not yet indexed by Play Store, but can be found by going to the http url.
Oops, the problem is: My 2 T-Mobile HTC 4G phones are not compatible with this app. Neither T-Mobile Samsung SGH-T679, and Vodaphone Samsung GT-I9000. Only works on Asus Nexus 7.
It's not like it will suddenly see mainstream adoption in any case. The project is young and the early adopters will be the nerds and the geeks who don't mind the bumps. It's always like this. Organically it can spread and by then it could both be a robust app and have prerequisites pretty much anybody fulfills.
> the goal is to have uncensorable, untraceable communication and file-sharing on mobile devices."
This is really interesting. How is this uncensorable? From what I've read, i2p requires defined servers to resolve addresses which themselves can be taken down.
That does not make it inherently uncensorable. China can still look at your traffic, go 'this is nightweb traffic' (or even just bittorrent traffic, I doubt they care about that), and block the communication. Bam, censored.
First, all they see is that is I2P traffic(or rather they see it's encrypted, as the protocol has no magic bytes anymore afair).
And secondly they haven't done much work in regard to blocking UDP afaik, so unless that has changed, they can't really censor I2P once you got it up and running.
What do you mean by base32 hostnames? ips? If you mean ips, then, especially on a phone, wont the ip change often. If you mean some actual hostname (presumably not the reverse lookup) then who translates that hostname? If it is provided by nightlyweb servers, then if that server gets taken down, you have no more network, right?
I mean the hostnames used by I2P itself. They behave like normal hostnames, but they don't require any DNS-style resolution because they contain your public keys inside the hostname itself. They are equivalent to .onion addresses in Tor, except a lot longer.
I understand that, you are saying that you have an id of who you want to talk to. The problem is, where do you start looking? Even with .onion you need an entry point to the tor network. It can be a DNS server, a web server, or whatever; but it must be hard coded (unless you start broadcasting on the local network looking for an entry, which I havent seen an example of). That is the problem. The first entry point can easily be taken down.
You have to bootstrap onto the I2P network initially. There are several IPs hardcoded into the router by the I2P project, which are run by volunteers. If these IPs are blocked in your country, you are out of luck.
There are a few possible solutions to this. First, allow users to add new bootstrap nodes to the app. Second, provide "meshnet" functionality to the app. I am considering both. The latter is much more complex to implement, but Android provides an API called Wi-Fi Direct which I could conceivably use to connect Nightweb nodes together if they are in close proximity. I'm open to other ideas.
Once you've bootstrapped/integrated with the network, it takes a minute or two for a new update to reach you in my testing. The initial time to bootstrap onto the network is around five minutes.
The traffic consumption is pretty high, because it becomes a full peer on the I2P network. Over a month I would expect it to consume around 1GB or more. If this becomes an issue for people, I may add the ability to be a non-contributing peer.
You might want to add a status text to the service notification, displaying how far bootstrapping is..
Please make the non-contributing status the default then, or at least ask the user on installation... capped data plans are still the default in many places... :(
Do android applications have access to their amount of data used? Maybe it would be possible to cap the data usage or lower the bandwith when a limit is reached.
Definitely agree with the option to become non-contributing, or at least introduce some limiting - it's a struggle to get a data cap of higher than 500MB here.
Speed doesn't seem too bad, even on 2 year old hardware.
Is there an (easy) method for transferring your key to another device, and conversely if there is such a way, is there anything to protect the file if someone was to get access to the device storage?
Yep I already added data export. Just click your profile and there is a button called "Export..." which will ask for a password and create an encrypted zip file.
It might make more sense to switch between the type of peer based on the type of network connection. If the phone is currently connected to wifi, then run as a contributing peer. If the phone is only on 3G/4G/LTE/etc then switch to being a non-contributing peer.
had the same idea a while back and was pondering how I would get past NAT if you are on a mobile network. does it work there as well? I'm assuming it will continue to work as long as your carrier doesnt block the respective ports.
also, don't take this personally - but if you're looking at targeting a broader crowd, you might have to update the UI to make it look more like traditional social apps.
I don't know how widespread NAT is on mobile networks, my
operator just started using it and I've been meaning to switch.. not a real internet connection anymore IMO. And lots of people are doing self-inflicted NAT on their home wifi. So it might actually be that mobile connections are less likely to be NATted.
I tested this behavior a little bit, it does not apply to the profile picture but when you submit an other picture it appears to be rotated 90° left.
So I manually rotated my pic 90° right to counter this, unfortunately the picture appears exactly the same way as before so I suspect it to not be just a rotation 90°left
I can concrete the problem. If i take a picture with my smartphone camera, this pic rotate. If i take a screenshot with my smartphone this pic don't rotate. I use a samsung galaxy s3 mini with android 4.1.2. I hope it helps (Sorry for my bad english) I'am native Kraut speaker ;)
I'll consider that in the future, but I'm not in a rush to solicit donations right now. If I decide to quit my job and work on this full time, I will definitely start begging =)
I wouldn't say it's an alternative, because CJDNS and I2P operate at different levels of the stack. In other words, you could theoretically run I2P on top of CJDNS. I like the project very much, though integration into Nightweb isn't likely because it requires the creation of a TUN device, which is a kernel-level facility and thus requires root permissions.
The main problem of Clojure for Android right now is the large size of Clojure runtime. This leads to two issues: a) long loading time (can take a few seconds even for the basic app), b) applications often gets closed by the OS once switched to another, in order to free that memory.
Since ProGuard is no help in optimizing Clojure-compiled code, the issues should be addressed in some other way. One that is possible is to write source-shaking compiler that will strip the final APK of the unused functions. It's pretty hard to do with the current compiler, but if we eventually write Clojure-in-Clojure compiler (there is a proposal for this year's GSoC by the way), it may be feasible to add these optimizations to it.
And finally a shameless plug: if you are interested in trying Clojure for Android, here are the links to get you started: https://github.com/alexander-yakushev/lein-droid https://github.com/alexander-yakushev/neko