Beta testing for upcoming 0.92 release

[Jeremy Lakeman]

While the list has been fairly quite of late, we have been beavering away behind the scenes getting ready to release a new version of Serval Mesh.

Highlights of this release;

- Overhauled and simplified the network connection activity.

- MeshMS text messages are encrypted end to end, with no plain text copy stored anywhere on your device.

- The peer list screen is more responsive and reliable. It will also indicate when a peer has become unreachable.

- Rhizome content synchronization is more efficient and more reliable.

- File content can be opened directly, without first saving a copy to your sdcard.

Release notes with more details are available here;
https://github.com/servalproject/batphone/blob/release-0.92/CURRENT-RELEASE.md

You can become a beta tester via the Google Play store, and automatically receive updated apk's by following these instructions;
http://developer.servalproject.org/dokuwiki/doku.php?id=content:servalmesh:google_play_testing

Or you can manually download and install release candidate builds directly from here;
http://developer.servalproject.org/files/beta/

[Nicholas Frota]

Hi guys, I’m a brazilian interface designer living in New York, and have been talking with Paul about serval project.

This email is part to introduce myself, and show you my progress so far. there’s a lot to unpack, so take your time.

The way I like to work is to present documents, discuss it, gather a list of changes, approvals, and iterate on the next version. rinse and repeat, till the deliverables.

deliverables range from wireframes, prototypes, docs, and change from version to version. I’m very agile and know my way on HTML, CSS pretty well.

Proposal

Me and Paul discussed my assumptions on mesh, and what serval wants to be. I list it all in the overall proposal, here: 

https://docs.google.com/a/nicholasfrota.com/document/d/1SSUG3gv9c5h4rTrDASS_lbWCCpDi46LKyjiv2Mr0JXs/edit#

One-on-one communication

the first flow to tackle is direct, private communication, and PDF is here.

https://docs.google.com/a/nicholasfrota.com/file/d/0B_lfhr7n4F8ob3FkVC0yb2Y3a2s/edit

Maps

the second flow to tackle is one-to-many communications. we agreed to place all broadcast communications on maps. for this one I have a loose proposal I need to discuss. It’s about how to make an app that stands on its own (no central authority needed, all tools available to use in your community) and also grows.

https://docs.google.com/a/nicholasfrota.com/document/d/1xUbRHLSBqdJ3LQMFCHyl8VjFO-azRVnmxKaf1mCb0gU/edit

Onboarding

the third flow serval needs is onbording: how to guide initial users from installation to use. that’s VERY important, even more regarding mesh networks. there’s a lot to educate. This one I don’t have much done, i do think we need to agree on a hangouts meeting and doodle something. without proper onboarding, there’s no adoption.

https://docs.google.com/a/nicholasfrota.com/document/d/1LLVHdCUPbCW-P8nB39NLSHNeuZc5JMzAjB9PxUrIcjs/edit?usp=drive_web

non-canon folder

I added all ideas and notes that are NOT official on this folder. I have a layout of QR system (barcode.pdf) and even some overall screens I designed before talking to Paul (screens.pdf)

https://drive.google.com/a/nicholasfrota.com/#folders/0B_lfhr7n4F8oZ2c0cm42REpUMmM

the folder is open for view, DO give me your google credentials if you want to edit. I’d love some collaboration.

As I told Paul, it’s hard to do design work for open source projects, simply because designs are not broken or fixed, we crave approval to go to the next step. I don’t mind doing it via email, but since Paul told me the core group is pretty small, I’d appreciate if we meet for a hangout soon. My 1hour talk with Paul helped me a lot, and I need to interview you guys properly. Otherwise it’s not design. just fancy pictures.

Take care, sorry for the long email, and do let me know your opinions.

—

Nicholas Frota     >>  frontend

                       developer,

                       graphic

                       designer, 

                       illustrator

+1(917)512-1486    >>  phone, 

                       viber

nonlinear          >>  twitter, 

                       github, 

                       instagram, 

                       readmill

nicholasfrota.com  >>  blog

[Jeremy Lakeman]

Just a few quick thoughts;

We aim to provide all of our services without an internet connection. But offline mapping is hard. There are some stand alone apps that can render map data from OpenStreetMap with offline map information. But you won't get the same integration as you would with say the web based google maps API.

I see the killer app for serval as building something like twitter, for a number of reasons;

- watching how messages spread from phone to phone can educate users on how serval works, and when it isn't working.

- getting news motivates people to form temporary network connections to swap messages. Meanwhile private messages are also being exchanged.

- broadcast messages can help to share encryption details for secure private messaging, without first meeting in person.

- we could allow you to search for and read messages before you have set up your own public identity.

Our current text messaging implementation doesn't store any timestamp information. This is mainly because we don't trust the clock on the sender and recipient's phone to be consistent or accurate. Of course we can add timestamps, but with asynchronous message delivery working out what time interval to use is complicated. Message sent time, arrival time...

As a side note, building a full ntp daemon into serval, so that we could know precisely how bad the clocks on an isolated network are, would make an interesting student project.

--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-dev...@googlegroups.com.
To post to this group, send email to serval-proje...@googlegroups.com.
Visit this group at http://groups.google.com/group/serval-project-developers.
For more options, visit https://groups.google.com/d/optout.

[Nicholas Frota]

I hear you. Asynchronous communication is the key.

I don't think a twitter like app is enough to bring users tho. It's doable use. Just not enticing.

And yes... Maps need to be downloaded. Regions need to be defined. If that's the case, it should be part of the onboarding.

Regarding the time, yes... It's complicated. There the time it's sent. The time it's received. The time it's read. That's a lot to take.

[Nicholas Frota]

Are local clocks THAT unreliable? Or is it just a 80/20 thing, we can build on top of it, just not use it in critical mission?

[Jeremy Lakeman]

It's hard to know, and it depends. If you don't have a cell tower to sync to, and you haven't synced to GPS time, the clock is whatever you set it to. It could be anything from seconds to years out of sync.

[Nicholas Frota]

Can we ask to check the time at the onboarding?

I understand it's a technical failure, but since user and system goals are aligned (there's no benefit for the user to fake the time) I don't think it's a big deal.

Is there any study that tells how many devices are not in sync? I take its not a deal breaker.... But maybe I'm glossing over.

[Paul Gardner-Stephen]

Hello,

From our own experience when we go to the field or a demo with a dozen phones, the clocks will cover a range of several years, and even those that are roughly in line will differ by minutes to several days.

Paul.

[Christian Huldt]

Would it be doable to use age, i.e. relative times?
Like time_sent - time_written or time_sent - time_received ?
And adding those in each hop?

Just hoping that the clocks are a bit self-consistent...

[Jeremy Lakeman]

Age vs your local clock should at least be understandable, but still may not be what people expect. eg "just now" when the message was written yesterday...