Some thoughts on the needs of users
2 views
Skip to first unread message
skyl4rk
Jul 25, 2012, 10:09:00 PM7/25/12
to Byza...@hacdc.org
Assuming that Byzantium is started up in a group of laptop pc's in response to an emergency, I can see two cases of users:
A. Support Team and B. Victims.
The support team is airlifted into the disaster area and has a specific humanitarian aid task to perform. Their needs are to communicate with each other, communicate with home base and to access relatively large pdf manuals, rules and procedures files for their organization. They may need to communicate with local organizations or the local population using a pc but this is less likely in the initial aftermath. They may need to order equipment and materials online via a web browser app. In an emergency situation, high bandwidth internet is probably not available although the support team may have low bandwidth internet available to them (cell, satphone, packet radio).
For initial communication before there is any access to internet, I would recommend a webforum type application instead of IRC. A forum allows for the creation of stickies and allows for searching of older posts. More people are familiar with webforums than IRC. IRC can work but there needs to be an instruction manual on how to use it.
For distributing large pdf files of manuals, rules and procedures, the options are to have one laptop serve all other users. This is somewhat inefficient use of the servers bandwidth since is it probably also serving other applications. I would suggest some type of torrent application so that any pc with even a piece of the document could serve parts of the document that is needed by all users. Perhaps there could be a persistant directory that is set up so that any document that is saved there would be made available as a torrent to other users and the torrent program would automatically start upon boot from CD.
When internet is available, the ideal method of communication is by email. Ideally, each support team member would have a gmail account and access it over the internet. I am assuming that an email server is too complicated to configure and set up. This may not be correct.
A cell phone application similar to villagetelco.org (asterisk) could be very useful to allow the use of cell phones in the local area even if cell towers are not working. This would allow the use of smartphones similar to walkie talkies, even if there were no connection outside of the local meshnet.
Support team services should be given priority and dedicated bandwidth.
Victim services. The most important victim service during an emergency is health and welfare traffic. Most of this traffic is family members calling in to the disaster area to try to find the status of loved ones. In this case, when internet access is available, some kind of forum or bulletin board could be used to post questions, and those who have information can respond. This should be set up in advance and hosted offsite. Requests for information on family member status should be referred to this website.
Some health and welfare traffic is related to medical advice. This should be given some type of priority and should be confidential. Perhaps a private IRC channel is best for this.
There needs to be a way to allow some groups prioritized access to internet. For example, there may be local government agencies that need an internet connection. There needs to be a way to separate this traffic and allow it a prioritized access to the internet. The Support Team needs prioritized access to the internet.
In some cases it may be desired to allow Byzantium to provide internet access to the public. For many nonemergency uses, this is probably an important option. For emergency services, it should be possible to limit the public's use of bandwidth so that critical communication has priority.
A thought about CDs versus USB sticks. I think that only the laptops with server functions need USB sticks and persistent memory. It is probably better in an emergency situation to limit the number of servers (USB sticks) but maximize the number of users (CD meshnodes). Otherwise some users will click on buttons and make mistakes and set up unnecessary services, which would cause confusion.
A. Support Team and B. Victims.
The support team is airlifted into the disaster area and has a specific humanitarian aid task to perform. Their needs are to communicate with each other, communicate with home base and to access relatively large pdf manuals, rules and procedures files for their organization. They may need to communicate with local organizations or the local population using a pc but this is less likely in the initial aftermath. They may need to order equipment and materials online via a web browser app. In an emergency situation, high bandwidth internet is probably not available although the support team may have low bandwidth internet available to them (cell, satphone, packet radio).
For initial communication before there is any access to internet, I would recommend a webforum type application instead of IRC. A forum allows for the creation of stickies and allows for searching of older posts. More people are familiar with webforums than IRC. IRC can work but there needs to be an instruction manual on how to use it.
For distributing large pdf files of manuals, rules and procedures, the options are to have one laptop serve all other users. This is somewhat inefficient use of the servers bandwidth since is it probably also serving other applications. I would suggest some type of torrent application so that any pc with even a piece of the document could serve parts of the document that is needed by all users. Perhaps there could be a persistant directory that is set up so that any document that is saved there would be made available as a torrent to other users and the torrent program would automatically start upon boot from CD.
When internet is available, the ideal method of communication is by email. Ideally, each support team member would have a gmail account and access it over the internet. I am assuming that an email server is too complicated to configure and set up. This may not be correct.
A cell phone application similar to villagetelco.org (asterisk) could be very useful to allow the use of cell phones in the local area even if cell towers are not working. This would allow the use of smartphones similar to walkie talkies, even if there were no connection outside of the local meshnet.
Support team services should be given priority and dedicated bandwidth.
Victim services. The most important victim service during an emergency is health and welfare traffic. Most of this traffic is family members calling in to the disaster area to try to find the status of loved ones. In this case, when internet access is available, some kind of forum or bulletin board could be used to post questions, and those who have information can respond. This should be set up in advance and hosted offsite. Requests for information on family member status should be referred to this website.
Some health and welfare traffic is related to medical advice. This should be given some type of priority and should be confidential. Perhaps a private IRC channel is best for this.
There needs to be a way to allow some groups prioritized access to internet. For example, there may be local government agencies that need an internet connection. There needs to be a way to separate this traffic and allow it a prioritized access to the internet. The Support Team needs prioritized access to the internet.
In some cases it may be desired to allow Byzantium to provide internet access to the public. For many nonemergency uses, this is probably an important option. For emergency services, it should be possible to limit the public's use of bandwidth so that critical communication has priority.
A thought about CDs versus USB sticks. I think that only the laptops with server functions need USB sticks and persistent memory. It is probably better in an emergency situation to limit the number of servers (USB sticks) but maximize the number of users (CD meshnodes). Otherwise some users will click on buttons and make mistakes and set up unnecessary services, which would cause confusion.
The Doctor
Jul 26, 2012, 11:56:45 AM7/26/12
to Byza...@hacdc.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/25/2012 10:09 PM, skyl4rk wrote:
> The support team is airlifted into the disaster area and has a
> specific humanitarian aid task to perform. Their needs are to
> communicate with each other, communicate with home base and to
> access relatively large pdf
Support teams tend to have their own comms equipment, which is a)
often not interoperable with whatever communications infrastructure
that is already in place, and b) lacking some features which we are
implementing.
> equipment and materials online via a web browser app. In an
> emergency situation, high bandwidth internet is probably not
> available although the support team may have low bandwidth internet
> available to them (cell, satphone, packet radio).
In the Katrina scenario, cell isn't realiable because the
infrastructure may not support it anymore (case in point, the storm
that hit DC a few weeks back). I don't know how common satphones are;
I do know that they're fairly expensive. Usually, it's hams who have
packet radio and they're usually doing ARES/RACES type stuff.
> For initial communication before there is any access to internet, I
> would recommend a webforum type application instead of IRC. A
> forum allows for
Planned - that's going to be an XMPP-with-web-frontend app.
> the creation of stickies and allows for searching of older posts.
> More people are familiar with webforums than IRC. IRC can work but
> there needs to be an instruction manual on how to use it.
For what it's worth, our IRC webapp 'just works' and can be used by
people who only know how to type. Test scenario: Guerilla wireless on
the Acella train last year, about 40 users that just saw 'Chat' and
clicked the link.
> For distributing large pdf files of manuals, rules and procedures,
> the options are to have one laptop serve all other users. This is
> somewhat inefficient use of the servers bandwidth since is it
> probably also serving other applications. I would suggest some
> type of torrent application so that any pc with even a piece of the
> document could serve parts of the document that is needed by all
> users. Perhaps there could be a persistant
This is why I keep bringing up Tahoe-LAFS: it's designed for this sort
of thing. The files on a single node are made available to every
other node running the app, and they're accessed with an HTTP
frontend. Put the files into a Tahoe-LAFS mount and every other
Tahoe-LAFS node can see and access it.
> When internet is available, the ideal method of communication is by
> email. Ideally, each support team member would have a gmail account
> and access it over the internet. I am assuming that an email
> server is too complicated to configure and set up. This may not be
> correct.
If the mesh has an Internet gateway, clients (and nodes, incidentally)
of the mesh can punch https://gmail.google.com/ into their browser and
get to Gmail.
> A cell phone application similar to villagetelco.org (asterisk)
> could be very useful to allow the use of cell phones in the local
> area even if cell towers are not working. This would allow the use
> of smartphones similar to walkie talkies, even if there were no
> connection outside of the local meshnet.
Does that assume that F/OSS cell tower equipment is set up in the
area? Or, does that assume that the cellphones have VoIP clients
already installed. Cellular's not my field, so these are probably 101
questions...
> Victim services. The most important victim service during an
> emergency is health and welfare traffic. Most of this traffic is
> family members calling in to the disaster area to try to find the
> status of loved ones. In this
And likely people calling for help, vis a vis Haiti suvivors tweeting
their locations.
> case, when internet access is available, some kind of forum or
> bulletin board could be used to post questions, and those who have
> information can respond. This should be set up in advance and
> hosted offsite. Requests
Again, we're going to implement this as an XMPP app with a web
front-end. This is a generalization of the XMPP microblog.
> Some health and welfare traffic is related to medical advice. This
> should be given some type of priority and should be confidential.
> Perhaps a private IRC channel is best for this.
Or user-to-user messages/DM's.
> There needs to be a way to allow some groups prioritized access to
> internet. For example, there may be local government agencies
> that need an internet connection. There needs to be a way to
> separate this traffic and allow it a prioritized access to the
> internet. The Support Team needs prioritized access to the
> internet.
That assumes that we know what services they access, what their IP
addresses are, et cetera. We can't just ask users "Are you a first
responder? Click here." because everybody will click on it, and it
then becomes pointless. That doesn't mean that we can't do traffic
shaping, we can, but the assumptions are not the obvious ones.
> A thought about CDs versus USB sticks. I think that only the
> laptops with server functions need USB sticks and persistent
> memory. It is probably better in an emergency situation to limit
> the number of servers (USB sticks) but maximize the number of users
> (CD meshnodes). Otherwise some
Not all nodes are expected to run servers, but all nodes are designed
to relay traffic.
> users will click on buttons and make mistakes and set up
> unnecessary services, which would cause confusion.
That's mitigated by the fact that the services we'er switching in are
all clustered - every node running a service not only presents a
webapp to the user, but the user's interactions will be federated to
every node on the mesh.
- --
The Doctor [412/724/301/703] [ZS]
Developer, Project Byzantium: http://project-byzantium.org/
PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1
WWW: https://drwho.virtadpt.net/
"The truth, as always, will be far stranger." --Arthur C. Clarke
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlARaLwACgkQO9j/K4B7F8EpWwCgts/A2oBb85OjJ2ojc09LnrMO
1LQAn2DrHxDV84YcC0n0Qf1eG6/L+hqw
=sVcC
-----END PGP SIGNATURE-----
Hash: SHA1
On 07/25/2012 10:09 PM, skyl4rk wrote:
> The support team is airlifted into the disaster area and has a
> specific humanitarian aid task to perform. Their needs are to
> communicate with each other, communicate with home base and to
> access relatively large pdf
often not interoperable with whatever communications infrastructure
that is already in place, and b) lacking some features which we are
implementing.
> equipment and materials online via a web browser app. In an
> emergency situation, high bandwidth internet is probably not
> available although the support team may have low bandwidth internet
> available to them (cell, satphone, packet radio).
infrastructure may not support it anymore (case in point, the storm
that hit DC a few weeks back). I don't know how common satphones are;
I do know that they're fairly expensive. Usually, it's hams who have
packet radio and they're usually doing ARES/RACES type stuff.
> For initial communication before there is any access to internet, I
> would recommend a webforum type application instead of IRC. A
> forum allows for
> the creation of stickies and allows for searching of older posts.
> More people are familiar with webforums than IRC. IRC can work but
> there needs to be an instruction manual on how to use it.
people who only know how to type. Test scenario: Guerilla wireless on
the Acella train last year, about 40 users that just saw 'Chat' and
clicked the link.
> For distributing large pdf files of manuals, rules and procedures,
> the options are to have one laptop serve all other users. This is
> somewhat inefficient use of the servers bandwidth since is it
> probably also serving other applications. I would suggest some
> type of torrent application so that any pc with even a piece of the
> document could serve parts of the document that is needed by all
> users. Perhaps there could be a persistant
of thing. The files on a single node are made available to every
other node running the app, and they're accessed with an HTTP
frontend. Put the files into a Tahoe-LAFS mount and every other
Tahoe-LAFS node can see and access it.
> When internet is available, the ideal method of communication is by
> email. Ideally, each support team member would have a gmail account
> and access it over the internet. I am assuming that an email
> server is too complicated to configure and set up. This may not be
> correct.
of the mesh can punch https://gmail.google.com/ into their browser and
get to Gmail.
> A cell phone application similar to villagetelco.org (asterisk)
> could be very useful to allow the use of cell phones in the local
> area even if cell towers are not working. This would allow the use
> of smartphones similar to walkie talkies, even if there were no
> connection outside of the local meshnet.
area? Or, does that assume that the cellphones have VoIP clients
already installed. Cellular's not my field, so these are probably 101
questions...
> Victim services. The most important victim service during an
> emergency is health and welfare traffic. Most of this traffic is
> family members calling in to the disaster area to try to find the
> status of loved ones. In this
their locations.
> case, when internet access is available, some kind of forum or
> bulletin board could be used to post questions, and those who have
> information can respond. This should be set up in advance and
> hosted offsite. Requests
front-end. This is a generalization of the XMPP microblog.
> Some health and welfare traffic is related to medical advice. This
> should be given some type of priority and should be confidential.
> Perhaps a private IRC channel is best for this.
> There needs to be a way to allow some groups prioritized access to
> internet. For example, there may be local government agencies
> that need an internet connection. There needs to be a way to
> separate this traffic and allow it a prioritized access to the
> internet. The Support Team needs prioritized access to the
> internet.
addresses are, et cetera. We can't just ask users "Are you a first
responder? Click here." because everybody will click on it, and it
then becomes pointless. That doesn't mean that we can't do traffic
shaping, we can, but the assumptions are not the obvious ones.
> A thought about CDs versus USB sticks. I think that only the
> laptops with server functions need USB sticks and persistent
> memory. It is probably better in an emergency situation to limit
> the number of servers (USB sticks) but maximize the number of users
> (CD meshnodes). Otherwise some
to relay traffic.
> users will click on buttons and make mistakes and set up
> unnecessary services, which would cause confusion.
all clustered - every node running a service not only presents a
webapp to the user, but the user's interactions will be federated to
every node on the mesh.
- --
The Doctor [412/724/301/703] [ZS]
Developer, Project Byzantium: http://project-byzantium.org/
PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1
WWW: https://drwho.virtadpt.net/
"The truth, as always, will be far stranger." --Arthur C. Clarke
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlARaLwACgkQO9j/K4B7F8EpWwCgts/A2oBb85OjJ2ojc09LnrMO
1LQAn2DrHxDV84YcC0n0Qf1eG6/L+hqw
=sVcC
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages