[jitsi-dev] Using the meet.jit.si service as a predefined service provider?


#1

Hello all,

This was briefly discussed during today's community call. As suggested, I'm
following up over email.

One of our (open source) software products is the Spark instant messaging
client. We are experimenting with adding video-conferencing functionality
features to it. In its most basic form, we're offering a "invite to video
chat" menu item when chatting one-on-one, and a "invite to video
conference" option in context of a group chat.

We're basing this service on Jitsi-based components. The client opens an
embedded web browser, that loads a Jitsi Meet client.

One approach in realizing this would be to point clients to existing Meet
instances, like the one on https://meet.jit.si - How would that sit with
you, as the owners of that instance?

We are working on alternative (and we believe, more preferred) setups. On
the server side, we're offering a plugin that allows one to very easily
install a videobridge and host the Meet application. If that plugin is
deployed on your network, then clients should at the very least prefer
that. However, not every server admin will deploy this. Having the client
be aware of a public service like meet.jit.si would still allow client
users to use video conferencing, irrespectively of what services are being
provided by the local domain.

In The Call, Aaron argued that it would be undesirable for data to flow out
of the local network (and use a public server instead) when users can
reasonably be expecting that data remains inside. That's a valid concern -
and we will certainly need to address that - but that's somewhat outside of
the scope of my question. That question boils down to: how do you guys feel
about our software making use of your servers?

Kind regards,

  Guus


#2

Hey Guus,

Hello all,

This was briefly discussed during today's community call. As suggested,
I'm following up over email.

One of our (open source) software products is the Spark instant messaging
client. We are experimenting with adding video-conferencing functionality
features to it. In its most basic form, we're offering a "invite to video
chat" menu item when chatting one-on-one, and a "invite to video
conference" option in context of a group chat.

We're basing this service on Jitsi-based components. The client opens an
embedded web browser, that loads a Jitsi Meet client.

One approach in realizing this would be to point clients to existing Meet
instances, like the one on https://meet.jit.si - How would that sit with
you, as the owners of that instance?

You are most welcome, as long as it is well understood that meet.jit.si is
a demo service and we provide no SLA as to its availability.

We are working on alternative (and we believe, more preferred) setups. On

the server side, we're offering a plugin that allows one to very easily
install a videobridge and host the Meet application. If that plugin is
deployed on your network, then clients should at the very least prefer
that. However, not every server admin will deploy this. Having the client
be aware of a public service like meet.jit.si would still allow client
users to use video conferencing, irrespectively of what services are being
provided by the local domain.

Sounds like a good idea!

In The Call, Aaron argued that it would be undesirable for data to flow out

of the local network (and use a public server instead) when users can
reasonably be expecting that data remains inside. That's a valid concern -
and we will certainly need to address that - but that's somewhat outside of
the scope of my question. That question boils down to: how do you guys feel
about our software making use of your servers?

Again, you are most welcome to as long as the demo aspect of meet.jit.si
and the inherent impact on reliability is taken into account.

Emil

Kind regards,

···

On Mon 26 Feb 2018 at 12:28, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

  Guus
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
—sent from my mobile