Kliento is a workload authentication protocol that brings the concept of Kubernetes- and GCP-style "service accounts" to the whole Internet in a vendor-neutral and decentralised way.It uses DNSSEC to embed the full chain of trust in the credentials, so servers won't have to query external systems during verification. Think of them as short-lived JWTs that can be verified entirely offline by the...
I'm leading the VeraId project, a decentralised protocol that allows you to securely attribute content to any domain name under your control. It's a bit like TLS, but signatures can be produced and verified without an Internet connection.VeraId combines DNSSEC with a new Public Key Infrastructure (PKI) to produce digital signatures that can be linked to a domain name. Consequently, every...
No ETA yet as the focus is on running small pilots so we can gather feedback before we gradually promote it more broadly.
Indeed, iOS is going to be a challenge for the reasons you mentioned. The fact that we won't be able to have a standalone app like Awala on Android[1], which serves local apps, means we won't be able to have a single app that people could use to sync data with couriers.
So, we're going to have to pick a poison. Either we don't offer the sneakernet on iOS, or we'll leave it up to the developer of every app to use an SDK to sync with couriers (meaning that the user would have to open each app to sync with couriers, one app at a time). "Fortunately", Android is pretty much the only mobile OS in the regions susceptible to Internet blackouts, so the former option is the most likely one.
I think I've seen an app like the one you describe, but I can't remember the name. There's also Bridgefy, which is more general purpose, but they provide an SDK that you may be able to integrate. I haven't checked Bridgefy in ages, but I hope they sorted out their security; it didn't use any cryptography for ages, and when they added it was all quite vague and opaque.
[1] https://play.google.com/store/apps/details?id=tech.relaycorp...
NASA and the rest of the space industry have done a fantastic job with the Bundle Protocol (BP) and other related tech[1], but I think they will need something like Awala running on top of BP as we start to send humans further and further into space.
With Awala running on top of the Interplanetary Internet, astronauts could use regular Awala apps, with no need to built custom integrations with things like social networks (once those too are supported on Awala).
[1] https://www.nasa.gov/technology/space-comms/delay-disruption...
However, at the sneakernet level, and at least today, I think the only region where it'd be useful would be North Korea, if this is ever used there. Interestingly enough, I'll be talking about this in the next episode of the Inside Awala podcast, in case you're interested: https://awala.alitu.com
I agree! But...
> 1. Making end applications implement your protocol (eg Facebook) makes it way harder to scale, simply because the enshittified big tech apps are unlikely to care. Now the apps will have to maintain a separate service and not get paid to do it.
My bet is that, once we gain sufficient ground, Facebook and other mainstream social networks will be interested in building an alternative clients powered by Awala, just like Twitter built "Twitter Lite" back in the day. It's likely to be a PR stunt.
OTOH, third parties could build such applications, as long as the social networks give them access to their APIs (without extortionate fees!).
Until we gain sufficient ground, we'll carry on with in-house Awala-compatible apps like Letro.[1]
> 2. Having deliberate physical couriers travel across borders are a massive risk
Agreed. But there are options to avoid travelling across borders per my reply here: https://news.ycombinator.com/item?id=41695801
> a hop to hop mesh network where connectivity can be easily established across all users (every user is a courier when they connect to unlimited mobile data or wifi) will make the network a lot more available
I don't think that's a practical solution. Bluetooth-based meshnets are rather cumbersome to use, and WiFi-based ones are not even feasible (on Android, for example, you'd have to root your phone). Also, the regions we're targeting have low-spec devices, where most won't have enough capacity to replicate so much data from their family/neighbours.
I couldn't post a reply to a message from shubhamkrm because someone flagged it. Honestly, I don't see how the comment would've violated the HN guidelines. They disagreed with me, but did so respectfully. I suspect someone may have perceived it as a violation to the following rule:
> Please don't use Hacker News for political or ideological battle. That tramples curiosity.
But I'd argue that deleting their message actually tramples curiosity. It wasn't a political or ideological message. The focus was ethics.
In the hope that this was a mistake, I'll quote most of their message below next to my replies.
---
> A major reason for Internet blackouts here is because in many areas, there’s a deep seated animosity between different communities due to historical and ideological differences. Internet blackouts are done close to any sensitive event, to prevent malicious actors from spreading misinformation/rumours and provoking riots
First of all, I like your summary of the situation in India because I think it's objective and brings its nuance to the front.
> Have you considered the ethical implications of your service in such cases?
I have.
India is the reason why I describe Awala's goal as "providing all human beings with uncensored and timely communication anywhere in the universe – without impairing the fundamental rights of other human beings".[1] That last sentence is mainly because of India.
I agree with the sentiment, or the problem that the government is trying to tackle, but I disagree with their methods. They violate the fundamental human rights of many millions of people -- predominantly in Jammu & Kashmir and Manipur -- whenever they disconnect entire regions, not just from the Internet, but from the outside world. Even the postal service has been suspended.[2]
I don't think it's all India's fault though. At its core, this is a content moderation issue. Those malicious actors that spread misinformation use large WhatsApp groups and the like, and the companies behind those products haven't done enough to address the problem, so local governments in India take the drastic decision to cut off the Internet.
> Are you willing to take the moral responsibility for the damage to life and property that could be caused using your service?
Rather than waiting for something like that to happen, I'm more interested in mitigating it in the first place. That's why:
- Letro[3], the first -- and so far only -- app to be powered by Awala, only supports 1:1 messaging. No groups yet, and when we do, we'll only support a relatively small number of people (TBD; not hundreds or thousands).
- The future functionality to support "broadcasting" information to many users already has built-in mechanisms to handle hate speech and misinformation.[4]
- As I work closely with anyone integrating Awala in their existing services, I intend to ensure that they have adequate plans to address hate speech and misinformation.
---
[1] https://awala.network/about
[2] https://www.aljazeera.com/news/2019/9/25/crackdown-on-lawyer...
Scuttlebut and SSB-powered apps like Manyverse focus on social media and decentralisation, which is more about "broadcasting" and gossip protocols, where the offline comms is a happy side-effect of their decentralisation goals.
Awala is a platform to make software communicate offline securely. Centralised services like Twitter[1], and decentralised ones like Letro[2], or even hybrids, are all possible.[3]
I'm not on a quest to decentralise the Internet. I'm on a quest to connect people to their loved ones despite repressive regimes and wars.
[1] https://github.com/AwalaApp/poc#relaynets-proof-of-concept (Awala used to be called Relaynet)
[3] https://awala.network/tech-overview#service-decentralisation
Great question! This is, by far, my biggest worry. Especially in North Korea if we ever launch there. This is actually going to be the topic of the next episode in the Inside Awala podcast: https://awala.alitu.com/
Long story short, there are measures that we've taken, and measures we will take.
Measures that we've taken include using another layer of E2E encryption for the data transported by couriers and minimising the metadata to such an extent that you couldn't see who's the sender/recipient, even if the authorities took the courier's device to a lab. This way, couriers couldn't be coerced into giving something they don't have.
Measures we will take include concealing the app. For example, it could look and behave as a calculator when you open it (even its icon and name could convey that), and you'd only see the actual app once you enter a particular math expression.
Also, the technology is getting independent security audits periodically. They're currently wrapping up the latest one, and the report should be available in the coming weeks.
As for China, that's a totally different problem: They do have access to the Internet, but it's heavily censored. However, we're tackling that problem too now, as we're adding a resilient VPN function to Awala, whose prototype was already tested in China: https://github.com/relaycorp/fanqiang-poc
The reason for this VPN functionality inside Awala is that, at the end of the day, every single region that's susceptible to Internet blackouts is also subject to Internet censorship when the Internet is available. So people shouldn't have to install multiple apps for the various types of censorship they will be subjected to at different points in time.
> They simplified the explanation a bit too much in some places and lost details in the process.
Please let me know if there's anything else that we could improve, besides the questions raised to the comment by Vampiero that you're replying to.
> I think this is the kind of connectivity that works in places with no other connection, like a village on top of a mountain, an area with long term power outage, places where internet is censored, etc
Indeed. It could work in those cases, but my priority are regions disconnected to the Internet due to government orders or a foreign adversary.
You raise good questions. I originally tried to keep it simple and wrote the documentation with my (prospective) partners in mind. They already work in this space, so they know the problem very well, and we'd usually have a few high-level conversations before getting into that kind of details, so I didn't want to bore them with things they already knew. However, things are changing now and we're opening things up to the public in the coming days, so these are things I need to document better.
> how such a network would be useful
We're trying to establish connectivity in regions where the national/local government, or an adversary in a conflict zone (e.g. Gaza, Tigray), deliberately cuts off the population from the Internet.
I'm talking about places where satellite Internet services, like Starlink, won't work:
- Conflict zones where the enemy controls the sky, as they could "triangulate" the location of the terminal. This is why Starlink can be used in most of Ukraine, but is too risky to use in other conflict zones.
- Regions where the government won't give a licence to the operator. For example, Starlink in parts of Sudan: https://www.theguardian.com/global-development/article/2024/...
> who the couriers are and how they actually deliver the cargo
A courier is an individual or a group of people who volunteer to transport the data physically, between the region without access to the Internet and a location with access to the Internet. They can charge people if they want to and people agree, but Awala itself doesn't handle anything to do with that, so it'd be more of a verbal agreement amongst them.
That location with access to the Internet can be a place within the disconnected region that the government is intentionally keeping online (e.g. hospitals, international hotels), or a place/subregion whose ISP is taking too long to take offline. Worse case scenario, it could be:
- A place near the border with another region/country, where they can use the 4G/5G cell towers from that place. For example: https://www.economist.com/middle-east-and-africa/2019/01/10/...
- Another region that the couriers can travel to. For example: https://www.aljazeera.com/features/2020/1/13/how-internet-ex...
> Or why that's desirable over just caching the messages until the internet is available again.
Because in many cases you never know when the Internet will be restored. And during that time, you have diaspora communities absolutely horrified after not hearing from close relatives for weeks or even months. Or, in the case of many North Korean escapees, potentially ever.
> And what about reliability? How long does cargo take to get to its destination? How often does it actually make it there?
Every situation will be different. For example:
- In non-conflict zones where the government doesn't have the capability to triangulate unlicensed Starlink devices, it'd take whatever it takes for the courier to drive/cycle/walk to that device. People have smuggled these things even in Iran, where the government does have some capability to detect them: https://iranwire.com/en/technology/133773-iranians-defy-inte...
- In places like India (the world's capital of Internet blackouts), where blackouts are regional, couriers could catch a train to another region as shown in the link above.
Awala is built to withstand delays of up to 6 months.
Yup, that's exactly the only use case I'm targeting (I'm the author of Awala)
> A really reliable low-bandwidth emergency network would be more useful. Something that forwards short text messages via phone to phone WiFi until they reach some place with more connectivity would be helpful in emergencies.
That's also useful, but I'm not sure about either option being more useful than the other. These are very different problems within the realm of offline comms.
The interesting thing is what happens when the Internet is unavailable. Check this out: https://awala.network/tech-overview#sneakernet
And this video in particular: https://awala.network/assets/diagrams/centralised-couriers.m...
- Gus (author of Awala)
I'm leading a project that needs protection from DDoS attacks, but I found that everything that we developers and operators need to know to mitigate such attacks is scattered over marketing websites and technical reports, which makes it really difficult to form a holistic view.
I documented my findings once I completed the research, focusing on the needs of developers and operators. Admittedly, it started off kind of selfishly, because I believe that the best way to understand something is by writing about it, but I also wanted to help out others in my situation.
I also hope to raise awareness about DDoS attacks. It's shockingly easy to launch one these days: Just google "best booter" and you'll find services that will let you launch an attack for as little as $5. Free trials are often available.
Finally, I'm actively looking for feedback from folks in the DDoS space. If you work for an organisation with a vantage point on DDoS attacks (e.g. CDN providers) or are a security researcher, your feedback will be much appreciated! Just as importantly, if you're a developer or operator, and find an issue with the website or its content, please let me know!
Cheers,
Based on my limited/high-level understanding of the SMSWB and TxtNet projects, your assessment sounds about right to me.
Re: UX for Awala-compatible apps, I totally agree it's going to be difficult for people who are used to standard Internet apps, like web browsers. In fact, I'd say it's going to be even more challenging for people in those regions where they do have smartphones/PCs but have never had any connection to the Internet.
In both cases, I believe the solution is to totally rethink the common UX patterns we employ in networked apps, where the lack of connectivity would be treated as an exceptional event that the user has to sort out.[1]
This is top of mind for me and I'm actively working on a partnership with other organisations in this field to produce a guide for UX designers. I'm hoping we get to announce it and get to work on it in the coming weeks!
On this note, just as an FYI, I'm leading the Awala project[2], which is a new computer network where compatible apps use the Internet when it's available, but can also switch to a fallback medium when it's unavailable. The only fallback medium we have today is a sneakernet, and SMS support[3] might be added in the future but only for high-priority messages (given how expensive and slow it'd be).
[1] https://smswithoutborders.com/ [2] https://awala.network/ [3] https://github.com/AwalaNetwork/specs/issues/81
Same here.
This is going to come across as a shameless plug, but implementing DTN tech is actually my full-time job and we've got a couple of projects that will address some of the issues you identified:
- Awala, a computer network where compatible apps can use the 'standard' Internet infrastructure when it's available, or fall back to a backup medium that tolerates delays of up to 6 months. https://awala.network/ - VeraId, an offline authentication protocol powered by DNSSEC. https://veraid.net/
The term may not be commonly used there, but like everything in tech, people often try to solve the same problems from different angles using different terms. Offline First is also roughly comparable to DTN and some people in the IPFS have framed it in the context of Offline First.
DTN can actually solve some of the most pressing communications issues we face today: 40% of the world population is permanently disconnected from the Internet, and many of those who are are subject to severe censorship (look up #KeepItOn).
(Apologies for the late reply. I'm new around here and I didn't remember that HN won't send me an email notifications for replies to my comments.)
Before getting into Relaynet, let's consider how Internet apps work: They have a client and a server, and the client is responsible for producing and delivering its own data. That means that the server must be reachable and ready to respond to each request, at the exact time each takes place. This architecture (called Remote Procedure Call, RPC) is fine when the Internet is available, but it breaks when the Internet is cut off and it's also incompatible with alternative transports because they add a significant latency.
By contrast, Relaynet apps use a radically different architecture: Asynchronous messaging. Instead of clients/servers, apps have "endpoints"; and instead of requests/responses, endpoints exchange "messages". Endpoints delegate the delivery of such messages to one or more brokers, which we call "gateways" in Relaynet. This way, the sender and receiver don't have to be reachable and ready at the same time, because the gateways will keep a copy of each message until it reaches its final destination. Consequently, when the Internet is available, gateways will use it and messages would be delivered instantly, but when the Internet is cut off, gateways will switch to a secure sneakernet (https://en.wikipedia.org/wiki/Sneakernet). Additionally, endpoint messages (called "parcels" in Relaynet) are end-to-end encrypted and signed, so gateways can't tamper with them or see what's inside.
Behind the scenes, Relaynet apps communicate over the Internet/sneakernets via two gateways: A private gateway (a standalone app on the user's device) and a public gateway (a server-side app). Say Twitter supports Relaynet and exposes an endpoint at https://api.twitter.com/relaynet: When you post a tweet, your Twitter app will encapsulate it in a parcel bound for https://api.twitter.com/relaynet, but instead of delivering the parcel by itself, it'd send it to its local private gateway, which will in turn send it to its public gateway, and which will finally deliver it to Twitter's endpoint. Now consider the case where the Twitter server wants to send you data: It'd post the data to your public gateway (e.g., https://eu.relaycorp.tech), which would in turn send to your private gateway, which will finally send it to the endpoint in your local Twitter app; in this direction, the parcel is bound for an opaque address derived from the public key of the endpoint (analogous to Bitcoin addresses).
Now, when the Internet is cut off, your two gateways get disconnected. That's when couriers (https://relaynet.network/couriers) would step in and provide a secure sneakernet. Couriers will physically transport parcels between a place disconnected from the Internet and one connected to it. However, since parcels contain the address of the recipient, and that address would identify the service when it's bound for an Internet host (e.g., https://api.twitter.com/relaynet), gateways will encapsulate those parcels in a new layer of end-to-end encryption -- You can think of it as an "offline TLS". So couriers (or anyone who intercepts them) won't be able to see or change the parcels being transported.
As you may have anticipated by now, for a preexisting, Internet-based service to work on Relaynet, its developer has to make client- and server-side changes to their software. Alternatively, if the service offers an API, a third party could build a Relaynet integration (that's what I did in the Relaynet proof of concept with Twitter: https://twitter.com/relaynet_/status/1089211336171679745). Also, if you're building a service from scratch, you could build a fully decentralised one that doesn't need any servers (see: https://relaynet.network/service-providers)
Relaynet won't need any new/special hardware: Private gateways will support Android 5+/Windows/Linux (macOS and iOS support is on the roadmap), so you can use Relaynet as long as your device runs on one of those platforms.
I highly recommend watching this 12-minute video to learn more about how couriers establish this connectivity and also to see a demo of the software couriers will use: https://youtu.be/UXuLz3q_6bo.
How could this have worked in Belarus? Let's first assume that the implementation of Relaynet is complete and at least one service (e.g., Twitter) is now compatible with it. Based on what I know about the situation (https://netblocks.org/reports/internet-disruption-hits-belar...), this could've been done:
- First of all, people should've ideally installed Relaynet and the Relaynet-compatible app(s) they wish to use before the election (whilst the Internet is available). Generally, people living under repressive regimes should aim to have Relaynet installed before contentious events like elections. Starting to use Relaynet without the Internet is possible but fiddly (https://github.com/relaycorp/relayverse/issues/1).
- Similarly, couriers should've (ideally) planned their routes in advance, especially if they'll be collaborating with other couriers or if they plan to use Latvian/Lithuanian/Polish mobile Internet operators near their borders (without actually crossing the border necessarily). Russian and Ukrainian operators could potentially work too. Couriers would've also identified places likely to remain connected to the Internet in the big cities (Minsk and Barysaw seem to have been remained connected to some extend, although a lot of that would've been government agencies: https://twitter.com/netblocks/status/1293522490355064839).
- When the Internet was cut off, couriers would've stepped in by doing their route: Stopping at one or more locations without access to the Internet, and eventually getting to the nearest place with access to the Internet (somewhere in Minsk/Barysaw or near the border with another country).
- Each courier is free to charge their users if they want to (which would be reasonable, considering the risk and work they have to do), but we're not supporting that in any way in the software. That would be entirely between the courier and the user.
PS: All of this complexity is abstracted away from the end user. As far as they're concerned, all they need to do is install the private gateway and it'll default to a public gateway behind the scenes. Also, we won't be using this terminology with end users: The private gateway will simply be called the "Relaynet app".
Is that really plausible though? I'm sure it's technically doable, but I'm not sure it's realistic or even a good idea if you could pull it off.
Who has the ability _and_ incentive to carry out such an attack? You could hire someone to do a DDoS attack, for example, but who would pay for that?
Let's say you've pulled it off. Have you considered the collateral damage?
Can we be certain that whoever has the capacity to do this will only ever use it "for good"? What's "for good" anyway?
Have you even considered that not all the people who remained connected in the country may be government officials? I don't know about this specific Internet blackout, but quite often other organisations (e.g., international NGOs, consulates/embassies, hotels) remain connected (see this for example: https://qz.com/africa/1884387/ethiopia-internet-is-back-on-b...).
If you're interested in the cryptographic and networking details, the specs is probably what you want. At least the introduction to the core spec: https://specs.relaynet.network/RS-000