Re: [briar-devel] Questions about Briar/Bramble for use in a social media app

[James M. <ja...@jm...>]

Thanks Michael!  No problem on the delay, I've had plenty to work on on my
end.  Replying:

That's great that you've gotten funding for the mailbox app-- I know that's
been hard for many, especially with the OTF situation.

Regarding one user per mailbox-- I worry about less adoption if you require
each user to set up a mailbox on a server.  I think most non-technical
people just want to install an app on their phone.  But I see how the
mailbox would see who is sending to whom, so it does have to be trusted by
the user.

Perhaps mailboxes would have the ability to send to other mailboxes,
instead of only receiving messages?  I.e. a message would go through the
sender's and receiver's mailboxes, and thus e.g. a receiving mailbox would
only see which mailbox a message came from (or is sent to), not which
user.  If the sending mailbox did serve multiple users, that would obscure
the sender somewhat.

Regarding a 15-minute delay of messages in iOS-- as you say, I think the
acceptability of that depends on the application.  For instant messaging,
probably not acceptable.  For FB-like social media, probably acceptable.

Interesting how one-to-one chats use a group.  Assuming that scales to
potentially thousands of "groups" (one with each friend, in my app), I'm
fine with using that approach.  Thanks for the detailed how-to and
explanation.

I also need some kind of contact/friend management system, including key
management, (most of which is automatic, right?).  I'm hoping I'll be able
to use Briar's system for that too.  It's probably the next part I work on,
before the message-sending part.

Thanks again,
James

[Sent from my phone.]


On Thu, Sep 24, 2020, 6:39 AM Michael Rogers <mi...@br...>
wrote:

> Hi James,
>
> Sorry for the very slow reply. Replies inline below.
>
> On 25/08/2020 02:52, James Marshall wrote:
> > Hello,
> >
> > I'm putting together a privacy-focused, open source social media app (I
> > posted here about it last year-- think FB but p2p, secure, and a much
> > better UX).  Briar/Bramble still looks ideal for the message transport,
> > and I have a few questions:
> >
> > 1) How is development of the "mailbox" tool progressing, i.e. the
> > always-up message receiver?  It's mentioned in the Briar FAQ.  I would
> > need something like this for my app.
>
> We've recently secured some funding to develop the mailbox app, using
> lessons learned from goapunk and bontric's prototype. That work will
> happen in parallel with the development of the main Briar app, and it's
> likely to take a couple of years.
>
> > 2) Can one mailbox receiver be used for many Briar users, or does every
> > user need their own?  It seems like all metadata except the recipient ID
> > could be hidden from the mailbox, so a mailbox wouldn't need to be
> > trusted much (though that could possibly open up a DoS attack that
> > floods the mailbox with unauthorized messages).
>
> Each mailbox will have a single owner, and will only be used for
> communication between the owner and their contacts. The mailbox won't
> have access to message content or group IDs, and will only be able to
> identify contacts by their Tor hidden service addresses. We can impose
> some kind of storage quota per contact in case a rogue contact tries to
> flood the mailbox.
>
> It would be possible for several logical mailboxes to live on the same
> physical device, but this might tend towards many people's mailboxes
> being run by a few providers, which would concentrate a lot of metadata
> in a few hands. So we're going to take a "one user, one device" approach
> for the default implementation and see whether users are content with
> that approach.
>
> There are many other directions we could have taken with the mailbox
> concept, and we're going to continue to research some of them. But
> "mailbox" will refer to this single-owner concept from now on.
>
> > 3) The FAQ says that the mailbox app could determine the feasibility of
> > the iOS version of Briar.  Any more insight into how possible the iOS
> > version is?  Even if it's not perfect, would the best possible be good
> > enough to be useful?
>
> I'm not an iOS expert, and to answer this definitively we'd need to find
> one. But as far as I can tell, the situation is this.
>
> Once the mailbox exists, it will be possible to build an iOS version of
> Briar that doesn't need to run constantly in the background (which is
> forbidden on iOS) to provide a Tor hidden service. Instead, the mailbox
> (running on another device) can provide the Tor hidden service, while
> the Briar app wakes periodically using the iOS "background fetch"
> mechanism and connects to the mailbox to check for messages.
>
> Background fetches are scheduled by the OS, and Apple's documentation
> doesn't seem to give any guarantees about how often they happen. But an
> older version of the docs mentioned 15 minutes, so we can use that as a
> rough estimate. That means messages may be waiting on the mailbox for 15
> minutes before Briar collects them and notifies the user.
>
> Is that an acceptable delay? I think it depends on the user and the use
> case, but there are certainly going to be some people who think a
> messaging app should deliver messages quicker than that. So the open
> questions are:
>
> 1. Is the estimate of 15 minutes realistic on current versions of iOS?
>
> 2. Are there any scenarios (e.g. power-saving modes analogous to
> Android's doze mode) where background fetches run less frequently?
>
> 3. Would a significant number of iOS users be willing to tolerate
> setting up a separate mailbox device and waiting 15 minutes for messages
> to arrive?
>
> > 4) My app would only need one-to-one messaging, not group messaging,
> > e.g. a post to someone's 500 friends would be 500 individually encrypted
> > messages.  I picture a simple API function like:
> >
> >   send_message(msg, recipient_id) ;
> >
> > ... plus an event on the receiving side, and possibly some
> > contact/friend management functions.  Is there an API, and does it
> > provide something like this?
>
> To send a message, you first need to create a group. This is a
> publish-subscribe context that the sender and recipient of the message
> must both subscribe to.
>
> Briar's one-to-one chats, group chats, forums, blogs and even
> introductions between contacts are all implemented using groups.
>
> Create a group on both peers via GroupFactory#createGroup(), and add the
> group to the database via DatabaseComponent#addGroup().
>
>
> https://code.briarproject.org/briar/briar/-/blob/4e5f2e31df85cb6d56559bb99bc921d322f6a1af/bramble-api/src/main/java/org/briarproject/bramble/api/sync/GroupFactory.java#L11
>
>
> https://code.briarproject.org/briar/briar/-/blob/4e5f2e31df85cb6d56559bb99bc921d322f6a1af/bramble-api/src/main/java/org/briarproject/bramble/api/db/DatabaseComponent.java#L70
>
> Both peers must make the group visible to each other via
> DatabaseComponent#setGroupVisibility().
>
>
> https://code.briarproject.org/briar/briar/-/blob/4e5f2e31df85cb6d56559bb99bc921d322f6a1af/bramble-api/src/main/java/org/briarproject/bramble/api/db/DatabaseComponent.java#L552
>
> Now either peer can send a message to the group via
> DatabaseComponent#addLocalMessage(). The message will automatically be
> synced to the other peer when a connection becomes available.
>
>
> https://code.briarproject.org/briar/briar/-/blob/4e5f2e31df85cb6d56559bb99bc921d322f6a1af/bramble-api/src/main/java/org/briarproject/bramble/api/db/DatabaseComponent.java#L80
>
> To validate the message on the receiver side, implement the
> MessageValidator interface and register your validator at app startup
> via ValidationManager#registerMessageValidator().
>
>
> https://code.briarproject.org/briar/briar/-/blob/4e5f2e31df85cb6d56559bb99bc921d322f6a1af/bramble-api/src/main/java/org/briarproject/bramble/api/sync/validation/ValidationManager.java#L20
>
> Once the message has been validated it will be passed to the incoming
> message hook. Implement the IncomingMessageHook interface and register
> your hook at app startup via
> ValidationManager#registerIncomingMessageHook().
>
>
> https://code.briarproject.org/briar/briar/-/blob/4e5f2e31df85cb6d56559bb99bc921d322f6a1af/bramble-api/src/main/java/org/briarproject/bramble/api/sync/validation/ValidationManager.java#L29
>
> The validator and incoming message hook are separate because messages
> are allowed to declare dependencies on other messages in the same group
> (for example, a reply in a forum depends on the post it's replying to).
> A message will be validated as soon as it's received, and the validator
> is responsible for extracting a list of dependencies. Then the message
> will be passed to the incoming message hook after its dependencies have
> been passed to the hook. In other words, the hook always sees messages
> in order, even if they arrived out of order.
>
> Unlike Secure Scuttlebutt, previously received messages aren't replayed
> each time the app starts. If you want to get a list of previously
> received messages (e.g. to show a chat transscript to the user), call
> DatabaseComponent#getMessageIds().
>
>
> https://code.briarproject.org/briar/briar/-/blob/4e5f2e31df85cb6d56559bb99bc921d322f6a1af/bramble-api/src/main/java/org/briarproject/bramble/api/db/DatabaseComponent.java#L288
>
> You can store mutable metadata alongside each message to record things
> like whether the message has been read. Metadata isn't shared with
> peers. Groups can also have metadata, which is used for example to store
> the contact ID for a group representing a one-to-one chat.
>
> > For more efficient bandwidth usage when posting a large file, a
> > high-bandwidth-connected "outbox" server could also help, using Signal's
> > technique of uploading one symmetrically-encrypted copy along with the
> > key encrypted for each recipient.  That's just for a future version of
> > my app, though; I don't need it now.
>
> We don't plan to support this in the first iteration of the mailbox, but
> it could potentially be supported in future.
>
> > Thanks a lot!  If Briar does what I need, this would save me a huge
> > amount of development time.
>
> Hope it turns out to be useful!
>
> > Cheers,
> > James
> Cheers,
> Michael
>