Bringing Africa Online At Ascoderu with Clemens Wolff

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great.

When you're ready to launch your next app, you'll need somewhere to deploy it, so check out Linode. With private networking, shared block storage, node balancers, and a 200 gigabit network, all controlled by a brand new API, you've got everything you need to scale.

Go to podcastanit.com/linode

to get a $20 credit and launch a new server in under a minute. To get worry free releases, download Go CD, the open source continuous delivery server built by Thoughtworks. You can use their pipeline modeling and value stream app to build, control, and monitor every step from commit to deployment in 1 place.

And with their new Kubernetes integration, it's even easier to deploy and scale your build agents. Go to podcastinit.com/gocd

to learn more about their professional support services and enterprise add ons, and visit the site at podcastinit.com

to subscribe to the show, sign up for the newsletter, and read the show notes. Your host as usual is Tobias Macy. And today, I'm interviewing Clemens Wolff about how s codearoo is using Python to help communities in Sub Saharan Africa gain access to the digital age. So, Clemens, could you start by introducing yourself? Hi, everyone. I'm Clemens. I'm, my day job is I'm a software engineer at Microsoft in New York City, and I'm also the lead engineer of Asco DeRoux, as Tobias mentioned, which is a Canadian Congolese nonprofit.

And we're using Python to empower people in sub Saharan Africa to get access to efficient communication networks and, things like that. Do you remember how you first got introduced to Python? Oh, yeah. So that was a while ago. In college, I studied artificial intelligence as my as my main degree, and 1 of the courses there was a natural language processing.

And the lecturer of that course is Ewan Klein, and he is 1 of the authors of the NLTK book, which is a natural language processing toolkit in Python. And so we use Python for that course. And after that, I was just completely hooked. You know, it's a very powerful language, very clean.

My my programming experience before that was in Haskell, which is elegant in a certain way, but, you know, not exactly easy easy to understand and easy to access at first, And then Mhmm. Java. So compared to both of those, Python was a breath of fresh air, and I kinda used it for a bit of everything since then. You know, programmed a couple of games in it. Lots of web services, lots of little kind of operating system scripts and things like that. Definitely great language, great ecosystem.

Levels, all the focus on open source. Like, there's a package for literally everything on PyPI these days. Right? Can you describe briefly what the mission is for Escoderu

and how the organization got started and how you got involved with it? Alright. So the mission of Escoderu

is to connect

rural populations. That's basically it. ASCODERU actually stands for Action Suaziza Pro la Connectione Le Develop

Memorial, which is French for Suaziza's

action for connecting and developing rural areas. And, the Suaziza in that acronym stands for Enzola Suaziza, who is a radio technician from the Congo DRC who founded Escudero.

And, basically, Nzola has decades of experience working as a radio technician in developing countries like the Congo DRC, Tanzania,

Zimbabwe, Angola, lots of different places with lots of different nonprofits. And he always noticed a key issue, which is that all the villages where he was deployed to and where he was helping these nonprofits operate, they were always so isolated, and that means that innovation doesn't spread. There may be a great idea in village a. And then just because communication, transportation,

infrastructure is all quite difficult, another village with very similar situation very close by might not know about that. And so his idea was, let me fix that. And, initially, he wanted to just buy a solution off the shelf and deploy that to a couple of his communities in the Congo DRC, but then he found that there wasn't 1. And so he set out to find some technologists to help him solve this project. And back in 2011,

he actually developed a prototype of a solution that would enable rural communities to access efficient communication

methods and deployed it in the Congo. And that was based on hacked together

routers that were accessing cellular Internet and exchanging, exchange email database over that network connection. And so in that way, people could could just share the cost of the bandwidth and access the email in that way and communicate very quickly. And, yeah, that email access was batched, so you would only get new emails maybe once a day. But still, it's a lot better than having to

to walk for many kilometers to the nearest communication center or to the nearest, other village. So that was the initial prototype. And since then, we've been working on on improving that and making it more reliable and cheaper. And so the current incarnation of that project

and the primary focus of your efforts is on the Lacole project, which is a combination hardware and software platform. So could you describe a bit about

what that platform is

and how it's helping you to achieve the goals of Escudero as far as being able to help these communities gain access to the digital age and digital economies? Yeah. Quick backstory. Locoli actually stands for a type of split drum that was used in the Congo. And so Enzula came with that name. You know, back then, the ancestors was using these drums to communicate. Now let's let's rebuild that and make it bring it in the modern world. And, specifically, what we've done is we've built a hardware piece, which is based on cheap single board computers like Raspberry Pi or Orange Pi. So Raspberry Pi is $20 and Orange Pi is $10 from AliExpress.

So they're quite affordable. Then we plug a USB modem into that so that we can access cellular networks. And, you know, cellular networks these days are really everywhere. So 95% of the world's population currently has cellular coverage and 85%

in even the least developed countries. In a lot of countries like the Congo DRC or Zambia, they skipped the landline phase and went straight to mobile. So even in very remote areas, you have cellular connectivity, so we can leverage that for for data access. The main issue then really is that the data access is super expensive.

So in the Congo, for example,

1 dollar 1 US dollar buys you 10 megabytes of data. Now last time I checked, 10 megabytes of data lets me load up Gmail twice or something like that. Just, you know, developers,

as our bandwidth gets higher and higher in the countries where we're developing for our primary audiences, sites get bigger and bigger. And that means that in less developed areas, the bandwidth costs really escalate quite drastically. And so with locally, we're trying to fix that. So we're deploying this, let's say, Raspberry Pi to a village, and then it creates a Wi Fi access point. You, as a user, would connect to a Wi Fi access point with a device like a cheap laptop, cheap phone, something like that. There are plenty of those out, and companies are always happy to to, you know, donate those. And then, on the on the on the Wi Fi network, you can access our locally running email application. We made just a very simple Python Flask application for reading, writing emails that we can, you know, localize into all sorts of local languages like Lingoda or Kikongo. And then, once per day or whenever bandwidth is cheap,

the we have a some logic in there that will purchase some bandwidth,

from a local data provider

and then exchange

the emails that were written on the device with some services that we have in the cloud. And we compress them. We kind of try to save as much bandwidth as we can on that initial expensive transfer

from the village to the cloud. And then in the cloud, we have some services that pick up these these transmissions

and, unpack them, you know, turn them into proper emails with all the MIME headers and stuff like that and send and actually receive them. So the idea really is to, at all cost, minimize the amount of data that you have to use to get from the village to the cloud. And given that now we're also in control of when people will access the emails or rather when we actually need to purchase the data, this is another couple of, interesting properties like being able to make use of bandwidth discounts. So as you can imagine, mobile networks aren't busy,

always at the same time. And so in the Congo, for example, during night times, like, 2 AM to 4 AM, you can actually buy a gigabyte of data for a dollar. And a gigabyte, that's that's a lot of bandwidth. Right? And so for this 1 gigabyte, we can just take an entire community's emails of a 100 people or more, compress them and exchange them, and still just the same cost. It's still just $1.

Right? So, basically, with this with this platform, we can enable people to pull their resources, and in that way, access the service that otherwise would be out of price range. And

when you're doing this bandwidth

purchase, are you introspecting

the size of the data on disk at the time that you're exchanging it so that you're only purchasing as much as is actually going to be used for that particular transaction? Or are you able to purchase a larger amount in bulk and then be able to preserve any unused amount for our future transmissions?

Yeah. So that really depends on the country. So right now, we haven't implemented anything super clever there yet. So right now, we're just purchasing

a gigabyte, basically, because we just assume that that'll be enough, and then we're using that to transmit. But as you say, 1 of the unfortunate things about that is that we do have wastage. Right? So we do have the situation where we buy a gigabyte, and then we don't use all of it, and it will expire within 12 hours or whatever the network provider, establishes there. So 1 interesting improvement would certainly be to be more granular in how we purchase the bandwidth

and, save even more in that way. However, in the countries that we're currently targeting, which is Congo DRC, Uganda, and Tanzania, a lot of times, the smallest unit you can actually purchase is $1. And so during nighttime, that will still just give us the smallest unit, which is a gigabyte. And so we just go with that for our MVP currently. As far as the

data transfer, you mentioned that you compress it as much as possible. And when I was looking at some of the documentation for the web application, it looks like you are using JSON for the actual

serialization

and data transfer format. Have you also looked at using any natively compressed or binary formats, such as Avro or Messagepack for being able to decrease even more the amount of space that's required for transmitting that information? Yes. Absolutely. I'd love to do that. The only reason we're using gzip and JSONL right now is because it's quite easy to write in a streaming fashion. So sometimes our devices, like an orange byte, they have half a gigabyte of memory. Right? So depending on how many emails are sent, it's really good to be able to just incrementally

write the compressed form, which, gzip supports.

But that's definitely an area that I'd like to explore more is what sort of other compression formats and serialization formats out there could we use to reduce the bandwidth use even further. Right now, we went with gzip and JSON because, you know, Python style library makes it extremely easy to work with those. And so that's that's kind of our our initial proof of concept implementation, but, I definitely love somebody to to look at that who has more experience in in this area than I do and and help out with that. That'll be amazing. And what are some of the other types of constraints that you have

had to work with in terms of how you design and build the application that's running locally on the devices that you're deploying in terms of being able to ensure that they are resilient

to error conditions

and able to run on the limited hardware that you're working with? Yeah. So there are really constraints from a number of of aspects, and 1 of them actually starts even just at the user interface. Right? So how do people interact with this with the software? And 1 thing to keep in mind here is that local day for many users will be the first time interacting with any sort of more modern technology. Right? We're really trying to bring this modern and efficient communication technology to areas where there hasn't been access to that yet or at least not much access. And then imagine you put somebody who's never really used a computer that much in front of Outlook or Gmail. And as much work as the designers put in there, to make those accessible, they're really still aimed at, let's say, Western audiences, people like you and me. So 1 of the design constraints we actually were working with is to make the interface as simple as possible, and as uncluttered as possible so that anybody can really use it in itself explanatory. That's 1 constraint from a design point of view. Another constraint, and that was actually an interesting 1, is translation and localization.

So many packages will say that, well, French is a language and English is a language and German and Italian are languages, and I can translate between those. But then what happens when you're using,

local languages like, Lingala, Kikongo that I mentioned earlier? Those don't often don't even have an official language code. And so that's another reason why we chose to actually build a custom email client so that we are in full control of all the strings and, you know, can implement translations for languages that may not be recognized as languages. So that was an interesting constraint from, like, a I 8 end point of view. In terms of actual technical constraints,

there are so many things that can go wrong.

So sending

emails from a Raspberry Pi or an Orange Pi and dialing up to the network and things like that, there are so many tools that need to work together. So you have USB mode switch to get your modem

from data mode into actual,

modem mode, and you have to find all the magic bytes for each particular modem to switch them into that mode. And that can go wrong, and it can fail for random reasons since you don't have any debugging output except for the color of the LED of the modem. Then you have, we w v dial to actually do the connection. And 1 big constraint and issue there is, how do you get the correct credentials

and the correct configuration

to dial up to a SIM card from, say, the Congo DRC or Benin. And GNOME actually maintains a database of configurations for a lot of SIM card providers. So, for example, they have support for Vodacom and Orange in the Congo, but in some countries are completely underrepresented in their database. So I was recently looking into setting up a locally for Benin, and there are 0 configuration entries in the database for Benin. So it's like, now I have to reverse engineer the SIM card protocol for this particular provider in Benin and

see see how to actually connect to that. And often, that's very difficult to do. Like, I'm based in New York City right now. And so that adds another layer of complexity on top of that. Right? Like, how am I gonna

dial with the SIM card from the Congo into,

let's say, AT and T network in the United States. Right? So that's that's another level of complexity. And then in terms of retries

and fault tolerance, you know, network connections are unreliable, especially in developing countries. And so we have to have a lot of robustness and reliability in there so that if the emails don't manage to get sent this time, they'll get sent, you know, on the next scheduled,

update and things like that.

It's definitely a lot of

a lot of trial and error and a lot of robustness engineering that needs to go into a product like this. And another constraint, of course, also is once you've shipped the product, it's shipped. And it'll be extremely difficult to actually update them because the update would consume a lot of bandwidth, so we don't wanna burden our users with having to pay for that. So it's really a lot of, upfront testing,

necessary.

Yeah. I was gonna ask about the,

update aspects of how you manage to release patches or bug fixes, whether that's something where you would have to go and physically,

you know, swap out an SD card or perform the software update in place when you're physically present with the device and how you would manage that from a scalability perspective.

And then as, second question on that, I was curious

who the actual customer is for these devices as far as who's actually,

purchasing them and how you maintain power for them to ensure that they're usable by,

the various communities where they're deployed?

Right. So for the update path, right now, we don't have a good model for that. And, I mean, there are several technical solutions. Like, you can set up a SIM card to receive SMS messages, and you can use Twilio to send those SMS messages and then remotely trigger maintenance actions. Right? That's how you'd normally do this in in an IoT project, or you can use a product like, Azure IoT Edge or whatnot. Like, there are a bunch of ways in which you can trigger an action on a remote device, but then we don't want to burden the the user with the bandwidth cost as previously said. So 1 way that we thought about that, if there really is a very critical update that we need to do, is we aim to have ambassadors in our target countries, like people who are really bought into the project and basically

fund them to go around the various communities and swap out the the SD cards and transfer the data and things like that. So we'd, basically the SD cards,

the SD cards rather. But that's that's definitely a hard problem and something where I don't feel as though we have a very satisfying solution right now. In terms of who actually pays for this, so that's an interesting question. So we're definitely targeting rural communities, and the idea is that community would come together, pool their money, and purchase 1 of these devices. And that's something that Zuora actually verified in 2011 with this initial,

with this initial prototype that there is definitely a market for this. People were just so keen and so eager on on buying the prototype and, you know, continuing to work with that. However, we also do realize that oftentimes,

this may slightly be out of the reach of some communities. And so 1 of our thoughts there is to market the device to nonprofits

that often have operating budgets. For example, we're we were talking with Poda and For the Love of Africa. They're 2 non Canadian nonprofits that that are operating in the Congo and Uganda and, you know, sell the devices to them, and they would deploy them to their community health clinics and their libraries and their schools and operate them there And, slightly mark up those devices over the actual cost of the hardware and then use the funds from those deployments to subsidize actual local purchases. So let's say your village in Bumbu and you wanna purchase 1, you'd pay price x. And you're a nonprofit, you'd pay price x plus some markup that we use for for subsidies going forwards.

And as far as the actual

work flow for people in these communities who are interacting with Lukole, can you walk through what that interaction looks like for somebody who's first coming across it and then as they use it for being able to manage their communications with the platform?

Sure. So

let's say somebody purchased it locally for your village or a locally just arrived. You plug it into a power source or into a solar panel. So we actually did some tests, and, you know, we can we can element the,

Orange Pi and the Raspberry Pi with sync with a simple solar panel. So you plug that in, it powers on, and it creates a Wi Fi network.

It has some default credentials. You connect to that with your device, and then you just make an account. You go through a simple flow in our Flask app that asks you, what's your name? What's your password?

And then it allocates an email address to you. And that email address will be your name at the location of the device. So there is a hard coded string that gets created at device time, device location time. That is a unique identifier for the device. Let's say the name of the village, like Bumbu or the name of the nonprofit in a particular in a particular project. And then after you complete the sign up flow, you have an email address. That's your name at device name dotlukole.ca.

And then you'll be able to, in the UI of the of the email application, write emails. And then the next time that it synchronizes,

those emails will get transferred to the cloud,

sent, and anything that was sent to your name at

device name dot locally.ca

will get downloaded until we able to see it in in the email application. So it's a very simple flow from a user's point of view, which is the basic the basic email flow. Then this is something that we're currently working on to to build on top of that, to add more value via email beyond just communication,

is, can we make integrations that use the email protocol and give you more rich information? And the inspiration for that really was,

when I was living in Zambia and Southern Africa, I was doing correspondence courses, for for German. And, you know, I would receive

lessons via snail mail and, you know, complete them and then do some assignments and pop them into the snail mail again. And, eventually, I'll have them graded. And then that led to the to the thought of, can we use email to recreate this

education access, for example? So we're currently talking with some teachers, like retired teachers organizations in Canada to see if there would be people who'd be willing to donate some of their time to, for example, remotely teach a classroom via email.

So that as a student, you'd sign up for a classroom, you send an email to a particular mailbox, and then that gives you back the list of all the classes, and then you register for a class also via email. And then we would parse that email and sign you up, on the service side. And then the teacher would send you assignments via attachments,

finish them, and reply with your solutions to that email. And we can basically stitch all of those courses, all of that correspondence together via some identifiers that we include in the email. A bit like how, you can send email

messages to respond to GitHub notifications and things like that. So that's 1 service we wanna build on top of on top of the email protocol and then other things like access to medical databases. Let's say you send an email to a particular mailbox like medical data at locally.ca,

and there is a query in there. We execute that query for you, searching against some medical databases and give you back all the results. You know, there are so many information flows that you can build on top of this communication protocol. It's a bit like the recent trend with chatbots. Right? There are so many things that you can can encode in a conversation between 2 people. And then the transfer protocol between that, in our case, would just simply be email because, you know, we can re leverage the entire infrastructure, compression, and all that good stuff. And

beyond

the types of services that you're thinking about building, what are some of the other

use cases that these communities have for

using email as their window or gateway into

the,

broader Internet,

and what are some of the limitations that are imposed by that being the only interface?

Yeah. So it's kind of interesting because, as you say, email is a bit limiting because it's asynchronous, it's scheduled, it's time delayed. Right? So how useful can it really be? And from from my experience,

it's really quite useful, and there are not that many things that you can't model in this kind of email conversation flow. So a really surprising use case actually was,

this, for agriculture. So So my dad actually is an agricultural engineer and has been working his entire career in in rural development in African countries. And 1 of the big issues in rural development is if you're, let's say, a subsistence farmer and you still sell some of your products and,

you know, to make to make a bit of money on the side, you live in village x and then you go to village y to to sell your wares on market day.

And you have to make a choice on the types of wares to bring. And sometimes you're lucky, and you make the right decisions and you sell everything. And sometimes you don't sell everything, and then you have less money available. So 1 super interesting thing,

over email that we could also do that I never thought about before is to make this marketplace via email where you may basically make purchase orders

and, offers via email, and then you only need to bring the things that people already basically paid for to the market day and, just collect the money and exchange the goods. So that's a really cool thing that we can build on top of that. And something that I didn't consider, you could actually model as an email interaction beforehand. Then some things, of course, you can't really model as a as a this asynchronous flow. And those are browsing scenarios where you're just, I don't know, checking Facebook or doing a random research and following links and things like that. That will be really frustrating over this time delayed flow. And, for that,

we don't have a great solution with locally right now, but there are several other projects that offer you,

access to some information that's more read only style. Let's say I'm, you know, on a blog reading some stuff, and then I follow a link to another blog. I'm just consuming. I'm just reading. Right? I'm not communicating back to that medium. And so that's actually a slightly different problem and can be solved in different ways. So for example, we're working with, Outranet recently, which is a project

that uses some spare satellite frequencies by the European Space Agency to broadcast

a read only copy of the, quote, unquote, useful Internet over satellite. And then you can just add a satellite antenna to your Raspberry Pi and receive that data anywhere in the world for free. And they broadcast Wikipedia. They broadcast various blogs, various news articles, things like that, weather data. So you can get off this read only data with a different channel than locally, and you can consume it in that way. And once we have a technology deployed in a village, you know, there's so many things we can build on top of that. Like, for example, this alternate integration. And then we can use locally for basically readwrite communication that's asynchronous and time delayed and other mechanisms such as alternate or there are other projects like Internet in a box, which puts Wikipedia and a bunch of other stuff just in a static copy on on a device and, you know, use that for the more read heavy flows with more interaction that wouldn't be modeled very well via via email. And so now that we've covered a bit more about the user interaction

and some of the high level design aspects, can you dig a bit more into

the mechanics of how the system works both on the locally

web application side as well as the cloud service that you have backing it? Totally. So on the locally itself, we have a Flask application.

Simple Flask application with all the good stuff with Flask login and the Flask assets and all of that standard stuff that you'd have for your standard

server side rendered web application. I really like Flask because it makes a lot of things super easy, and there's a middleware and a plug in for everything else. And it makes it also super easy to make very simple and robust sites that work on a lot of browsers. So we have fairly minimal JavaScript just because the kind of devices that will be used will be, you know, fairly low end and potentially quite old. And so fairly limited JavaScript, fairly limited CSS.

And Flask makes all of that stuff really easy. On the locally, we also have another Python script that's a really cool script called,

make vvconf,

which is a script that takes this, database from deviant that I mentioned earlier from from that,

has all of this information about various SIM card providers and then parses that in some big XML file, basically, and parses that and spits out a configuration file for vvconf, which is a tool in UNIX to dial up an actual an actual modem connection. And that tool is written in Python. And, actually,

it was distributed as part of Arch for a while, I think, and then it's the maintor dropped it or something like that. And, anyways, it supports, like, Python

2.0

or something like that. And so I recently forked that and modernized it and made sure that it runs on Python 27 and later. So so we maintain a fork of that. And it's a really cool tool, and more people should be using it and really contributing to that database of SIM card information because it just makes the world a better place for everybody

and for every Ubuntu installation. Every time that you put a a USB modem into a Linux box, basically, using that database. Right? So the more data we can get in there, the more information we can get in there, the better. And then on the service side, so we're hosted in in Azure currently because we we're nonprofit. So we get a grant from Microsoft of $5, 000

cloud credits per year,

which

right now covers everything that we're doing. And we have a bunch of services deployed to Kubernetes

just to make management easier.

And we're using a really cool framework there for the actual,

web API side, and that is connection by Zalando.

And, basically, in connection, you write a open API or swagger file describing your API. Like, let's say, I have endpoint a, and it takes a post request. And in the post request body, you have, let's say, the name of the client. And then in the URL parameter, you have a token. And in the header, you have something else. Then you just add an annotation to that, and that annotation is the fully quite fully qualified path to

a Python function.

And then connection will take care of taking the request, validating that all the data that you said is there is there in the different parts of the request, and then just calls your function.

And that's just normal Python function at that point. It doesn't even it's not even aware that it's part of a web framework. It just gets to different data that connection pull out from the request passed into those arguments. And that's super powerful because, first of all, you write the Swagger file first. So you have really good documentation for all of your APIs, and you don't need to write any custom code for validations

and data serialization, all of that stuff. That's a really cool framework. We're also using

SendGrid with as the actual email provider. So when we send an email that was transmitted from locally, eventually, it ends up in the cloud, and then we're using the SendGrid Python SDK to to send those emails. It's also super easy to use. This, as I said, is something I love about Python. Right? There's a library for everything, and, usually, the libraries are quite delightful. And then we're also using a bunch of asynchronous mechanisms,

in in queues

to make sure that, you know, we can scale appropriately and

we don't drop connections just because, apparently, we're posting a really large email and things like that. And that's actually an area in Azure where the Python support is a bit lacking. So there are several really good queue technologies in Azure, like, for example, service buzz and Azure storage queues, but the Python SDK is all based on polling. They're all based on the rest, API, unfortunately.

So to get the messages, you can't just say, here is a message handler. Call this whenever a new message arrives. You actively have to go out with every 30 seconds and fetch new messages and act on them. So it's a bit lame. So to to work around that, we actually used a container pattern called ambassador container where we have a Python endpoints written in connection that just sits there. And then we have a a sidecar container to that, like a container that's scheduled to the same to the same node that actually uses the c sharp SDK for service bus, which has a AMQP implementation and so has kind of push notification style message receiving. And so whenever the message gets received, it then takes that and posts it to the service that actually does the message processing. So in that way, we get the best of both worlds. We can implement our logic in Python, and, still, we can get this really efficient asynchronous communication via via service bus and, and the c sharp SDK there. We're also doing a bunch of interesting stuff with images recently. So,

let's say you're writing an email in Gmail and you're including an image in that. Usually, those get included as a link. Right? And then when those get transmitted to locally and somebody opens the email, there isn't an Internet connection there to actually display the image. And so we recently pushed, pushed an update where now when we receive the email, we actually parse it. And any image that you have in line in the body, we automatically

fetch that base 64 encoded and put it into the image into the email so that you can actually see it on the local LAN. And we also resize it to to save space and to save bandwidth as much as possible. And we're using other Pillow library for that, like, really good image manipulation in Python. And on the client side, you know, Python is definitely

easy for doing development work, but for being able to target these lower end devices.

You know, it works well on Raspberry Pi, but for as you get smaller

and you're trying to save on energy consumption more,

it oftentimes

pays to have the trade off of using compiled languages. So I'm wondering if you've looked into using anything like Python or MicroPython

or even a different language implementation

for building the client side application. We haven't really looked into that that much yet because, yeah, we kind of want low powered devices, but not really we we're not really targeting low powered devices. We're just targeting the cheapest devices out there that often happen to be a bit underpowered. Like, Orange Pie is $10, and it has,

quad core processor with 1.6 gigahertz

and a half a half a gigabyte of RAM. So that's kind of low powered, but not that low powered. And if you go much lower than that,

we'd actually have issues finding the kind of hardware that we need because we need at least 1 USB port for the USB modem to to the dial up connection, and the board also needs to be able to supply sufficient power to to that USB port. And so a bunch of the more low spec boards actually don't supply enough power for for 1 of those USB modems. And so there is definitely a trade off there, but I'd say we're targeting the level where, let's say, we have half a gig of RAM

and, let's say, like, 1 1 plus gigahertz processor or something like that, which is not that low low powered. And so Python works pretty well in that context, And we're doing the entire, you know, setup with Nginx to serve your static files and

and things like that to ensure that different parts of the stack handle different things. And so, overall, we we utilize resources fairly well. 1 thing that will be interesting, though, is if we can find a board that is competitive in price with orange pie, so, like, $10 or or less, and then do the USB modem, the kind of dial up connection in a different way, like, let's say, with a custom GSM chip or something like that. And there are a bunch of things coming out in that space recently, but I haven't looked very deeply into those yet. Like, I'm not really a hardware person, so that's, that's not the reason we actually went with, Orange Pi or Raspberry Pi and Python because it's super simple to to get up and running. It's kinda super simple to find contributors and definitely,

definitely productive quickly. That's definitely something that,

would be interesting to to look more into.

And beyond some of the technical limitations

imposed by the environment and the platforms that you're deploying to, what have been some of the most challenging or unexpected aspects

of building and maintaining locally and interacting with the user communities?

So there are a couple there. So 1 of them actually is right now, Asco Deiro, we're an entirely nonprofit, and we're entirely

volunteer run. And as you can imagine, everybody's super busy, and so it's difficult to find consistent time to to work on these things. And, you know, I work on it nights and weekends, but it would be great, you know, to have more developers involved. And this summer, we have a couple of students from Cornell University. They have a tech for good club, and they're helping out with a couple of projects. And that's super cool. I'm so excited about that. But finding reliable contributors

that you can count on to actually work on and that can take technical decisions with you and everything, that has been absolutely a challenge. And, yeah, I mean, we're entirely open source. I think we're kind of working on a cool project with lots of different aspects from low level stuff to cloud. So there's really something here for everybody.

And still, it's difficult to find people who say, okay. I'll sign up for this for 2 hours a week or 4 hours a week or however much and then actually stick at it consistently. So that's a challenge. I guess it's a challenge in running any sort of open source project. Another technical challenge or another nontechnical challenge rather is, as I mentioned before, just, the lack of, the lack of presence of many of sub Saharan African countries in the Internet in general. Right? So this database of all the SIM card providers has 0 entries for Binin. How are you gonna deal with that? And that's that's not really an issue, let's say, if you were going to deploy locally to, let's say,

Canada. Actually, in Canada, there are some regions, some remote regions that have very similar connectivity problems to Sub Saharan Africa, just because there isn't cell phone network there. And,

Internet via satellite is super expensive. Right? And then I was speaking with some people who were on a very far north in British Columbia Research Station most of the day. And then once every now and then, they dial up via their their satellite Internet and then Windows updates and downloads a bunch of stuff and eats up all the bandwidth. And that's not ideal. Right? So even in those situations, it would be useful to use locally. And that's much easier in terms of configuration and deployment because, you know, Canada, British Columbia, lots of resources about different providers that you can access, etcetera. Not so much the case for, let's say, the Congo or Zambia

or Benin or Uganda.

And going back a bit to the

aspect of having an email be the only interface to the broader Internet, I'm curious about the problem of discovery as far as how the user would even know what email addresses

are available for them to be able to send correspondence to or be able to request information from for whatever their particular

needs might be?

Yeah. That's a great, that's a great point. And, we can address that in 2 ways. 1 of them is we currently compile a static list of kind of useful email addresses to services on top of email that we've implemented or that we are implementing,

into the client at creation time. Obviously, it's static list, though. So it's

useful because, you know, there are only so so many services that we can think of right now. But in the terms of updating that, we're we're thinking about actually uploading that list of, kind of directory of useful email addresses to the alternate and broadcasting it in that way. And the alternate integration is quite a bit more expensive because you need to have a satellite receiver and a bunch of hardware to decode the satellite signal. So it would only be really feasible for, let's say, nonprofits who are deploying that solution to to to really afford that upgrade. It's about $200 in total or something like that.

But then you at least have a couple of hubs that have always updating list of all the useful mailboxes that you can send emails to. And then you can use word-of-mouth basically to spread that further,

in addition to the to the hard coded list that's compiled into the client at deployment time. And also as another means of being able to update that information, have you considered having sort of a default mailbox that's built into the device that when you deploy it, it is able to receive email messages and then display them as a

notification or allow people to navigate to that mail box to be able to review the information that's there, to be able

to then update those lists or provide,

opportunities for being able to communicate with various people or services or organizations?

No. That's a great idea to have sort of, like, a newsletter of these are the services that you can use now and just send that out regularly to each of the devices. Yeah. I had thought of that. That's a that's a brilliant idea, actually. It'd be super easy to implement. And just have that as, let's say, an a special account on a device, and there's a tab that you can go to always see all the messages sent sent there. That's a that's a great idea. Actually, I should look into that. I'm gonna track it in the GitHub issue right after this podcast.

Alright. And so beyond locally, are there any other projects,

either technical or nontechnical,

that you

are planning on or starting to implement as part of the mission of Asco DeRue?

So right now, we're really focused on local and getting that out of the door and then seeing where we can take this email service, basically, and how how many things we can build on top of that. Just as another example,

recently,

there were elections in the Congo DRC, DRC, and 1 of the big issues with that election was that a lot of parts of the population were excluded from that just because it's difficult to get to the next polling station, etcetera. And so

Zolo was thinking, what if we can work with the government to have signed emails and to actually verify somebody's auth somebody's identity based on email and then use that for voting. Right? So there's so many things that you can build on top of that. And I think this email protocol is gonna keep us busy for quite a while. But another thing that we also wanted to look into is

how can we leverage what we built

and use it to empower other nonprofits with similar missions? I spoke about Internet in the Box earlier, which is a great nonprofit and mostly operating in Southeast Asia to my knowledge. And they basically distribute, like, a library of Alexandria style Raspberry Pi with Wi Fi to communities so that people get access to this read only information.

And, we were talking with them to integrate locally with that so that whenever people go to these hubs to, let's say, read Wikipedia or look up Khan Academy or something like that, they can also exchange messages with other people who went to the same to the same location

and maybe exchange, like, pointers to create information on the device or whatever to a bit more interactive component there. And so 1 of the projects from the Cornell University

this summer is actually to to work on integrating locally with, Internet in a box. And so I'm sure there are other nonprofits out there that are operating the similar space that we can that we can help out with, the things that we already built. And are there any other topics of discussion

or

aspects of the project and work that you're doing that we haven't covered yet that we should discuss before we start to close out the show? So 1 thing that I find quite interesting is

how increasingly

technology comes to the focus and to the forefront of so many issues. Right? We recently had all these issues with privacy, with Facebook,

and things like that. And then, you know, your self driving cars, and how is that gonna affect the the car industry.

But, also, technology is core to development and to to innovation.

And there's actually an initiative for the United Nations called sustainable development goals, and that's a set of ideas and of targets and metrics

of how we as a planet can measure our progress towards

getting everybody out of poverty and getting to a sustainable future even even for the Western world. And 1 of the things they clearly call out is the importance of technology.

So they have the sustainable development called 9, which, is about building resilient infrastructure, promoting inclusive and sustainable industrialization, and fostering innovation. And that's something where we, as technologists, can really get quite involved and help out with because we've been doing this for a while. Right? And as I said earlier, 95% of the world population has access to mobile cellular signal. So 1 thing I'm quite interested in is how will this

go forward, you know, that there is this increased focus on technology and

on innovation technology and development, and what can we as technologists do to help empower that and to accelerate that. And for anybody who wants to get involved or contribute to the work that you're doing, what would be the best way for them to do that? Oh, yes, please. So all of the things we're doing are open source on GitHub on our premise of license. So you can find our issue trackers. I marked a couple of them as good first fixes. So if you just wanna jump right in, get your hands dirty, that's an easy way to to get involved. There's really something there for everybody from

low level Linux hardware interfacing with modems and stuff like that, all the way up to Kubernetes and cloud services and everything in between on the stack. That's a great way to jump in or just open up an issue, introduce yourself, or send me an email directly to clemens@ascoderu.ca,

and I'll respond to that as soon as possible. We also have a Slack channel that that we use for all of our communication. Like,

you still have to get an invite to get to that, but everything that basically we communicate about is con is totally open. So we wanna be super transparent as an organization. Yeah. So reach out on GitHub or reach out to me via email, and we'll find something. Or find me on LinkedIn, send me a message there. And for anybody who does want to get in touch, I'll be sure to add your contact information to the show notes. And so with that, I'll move us into the picks. This week, I'm going to choose HubSpot.

They've got a free CRM that you can use, and I've been leveraging that recently for being able to

keep track of various conversations I have around the podcast. So it's been very useful for

getting organized for that and tracking tasks and emails that have been going back and forth. So

if that's something that you are battling with, it's definitely worth checking that 1 out. And with that, I'll pass it to you, Clemens. Do you have any picks this week?

So this week is super hot and humid in New York City, which reminds me a lot of when I was living in Mali in West Africa. And that always reminds me of Alifakatore,

great, blues musician, there's a blues of of Mali, Rolling Stones' top 100, guitarists of all times. If you haven't heard any of his music before, definitely check it out. It's super, super interesting.

Alright. Well, thank you very much for taking the time to join me and discuss the work that you're doing at Escoda with Le Colle. It's definitely an interesting project, and I'm,

interested to see how it pans out as you go forward. So thank you for that, and I hope you enjoy the rest of your day. Yeah. Thanks so much for your time and to everybody for listening.

The Python Podcast.init

Summary

Preface

Interview

Keep In Touch

Picks

Links

The Python Podcast.__init__