Local Jami user discovery

It would be really great to be able to discover other Jami users on the local network, for example through zeroconf (https://en.wikipedia.org/wiki/Zero-configuration_networking) and / or multicastDNS (https://en.wikipedia.org/wiki/Multicast_DNS).

This would be very useful for local mesh networks such as Freifunk (https://freifunk.net), because Ring would not depend on an internet connection any more.

There was already such an issue, but it was flagged as "zombie" and closed: https://git.ring.cx/savoirfairelinux/ring-project/issues/289.

Duplicate of ring-daemon#47. About the issue, I think it should be implemented as the third type of account — "LAN".

Agreed, even more useful so for those using WiFi Direct (out of range of a service provider / can't afford internet). Personally, I want to use it as a baby monitor (via a second phone in my car), but can't tether/afford a second data plan.

I see jami is written in python - while I don't have any python networking experience, I do know a little python if someone who knows the project better can spec out what the reliant modules / what the interfaces I'd need to provide are I can take a stab at it.

mentioned in issue #581 (closed)

As explained on issue #581 I believe this request is an important one.

Besides the zero-configuration technologies mentioned by @bugsug , I think it should also work within a normal network with DHCP and DNS, as it is the normal case for community networks (Freifunk, Guifi, etc), being mesh or not.

I think it should be implemented as the third type of account — "LAN".

Out of my point of view, we do not need a third type of account. Ring / Jami is already completely P2P for transfering messages and calls between the clients. We only need another method for discovering (e.g. zeroconf, multicastDNS; see the issue description above) the peers, because normally, there is no DHT with it's entry point available on the local network.

If it is implemented this way, you could communicate with your contacts on the more local network, but also over the internet if this local network is not available any more and it will not be necessary to have several keys / ids / whatever it is called.

With (more) local networks I mean all IP-based networks not being the internet.

added 1 deleted label

assigned to @mzhang

changed milestone to %Iteration 6

changed milestone to %Iteration 7

changed milestone to %Iteration 8

changed title from Local ring user discovery to Local Jami user discovery

changed the description

changed milestone to %Iteration 9

changed milestone to %Iteration 10

@da2x indeed this is used to auto-bootstrap clients, but still not to discover contacts :)

changed milestone to %Iteration 12

changed milestone to %Iteration 14

changed milestone to %Iteration 15

changed milestone to %Later

added to epic &3

I think making this a third type of account would greatly reduce the quality of the UX. A typical use case, as I see it, would be to add a contact who you will likely want to talk to again after leaving the LAN you are currently on.

The one LAN-specific feature I can imagine as a nice-to-have would be LAN broadcast chat rooms, to send a quick announcement to everyone on your local network, or LAN push-to-talk, allowing Jami to replace FRS radios and the like.

Even that seems like it would be best done with a persistent and discoverable group call, that one could rejoin after leaving the network (That would also take over the use cases of Nextel-like devices).

added typefeature request label

added severityhigh label

marked this issue as related to dhtnet#15 (closed)