Federation with WebRTC - the points against

As reported by Ruben here, on September 25th we had the first edition of “VoIP on the Beach”. This event provides experts in the VoIP field the opportunity to discuss topics that they consider critical. This time we chose “Federation with WebRTC” and decided to split into two groups: one discussing the reasons in favour of federation, the other on the reasons against.

I followed the group “against”, and took some notes.

First of all a question that was raised is around the definition and objectives of federation. Has federation the purpose of providing a sort of global identity? Were we talking about “identity federation”? Or having a better user experience, e.g. with people able to instantiate a call from a domain to another domain without switching application?

One weak point of federation appeared to be that it’s not considered able to guarantee security nor identity. If you’re using a single service, and there’s a security vulnerability, you can trust that service to solve it as soon as possible. How can you trust a chain of services to all patch the vulnerability? A similar point was made about end-to-end encryption in a federated environment.

Another is that it appears we’ve had the opportunity to federate various times in the past (see e.g. XMPP and RCS), but the perception is that it wasn’t a success. Why trying again?

A concern was raised that trying to federate services could limit the freedom of choice, and that aiming at a common set of features would impact the ability to innovate. In general, federation is not something that users want or perceive of value.

To summarise, while there isn’t a solution to connect people in separate islands, and potentially there are protocols and technology to achieve that, the reasoning against federation was related to the complexity of integration, the need for selecting a subset of features, and the doubt that security and privacy are in practice achievable.

I hope my notes give enough justice to the very interesting discussion I witnessed, and I look forward for new opportunities to talk about critical topics in the world of VoIP.

2 Likes

Thanks for your notes @giavac, and welcome to the Open VoIP Alliance! :smiley:

Another is that it appears we’ve had the opportunity to federate various times in the past (see e.g. XMPP and RCS), but the perception is that it wasn’t a success. Why trying again?

I think there’s definitely some truth to it, because technically protocol like XMPP have been doing federation correctly for many years though the adoption of it is lacking. I think that this adoption issue is more a social issue rather than a technical one. You said it best yourself:

A concern was raised that trying to federate services could limit the freedom of choice, and that aiming at a common set of features would impact the ability to innovate. In general, federation is not something that users want or perceive of value.

I would however counter this by saying that the XMPP standards foundation has ways to create extensions to the protocol called ‘XEP’ (XMPP Extension Protocols). Using these XEP features is up to the people running the XMPP servers however. I believe that doing federation in such a way does not impact freedom of choice, just look at the list of supported clients that all have their own functionality/UI but in essence do the same thing. I would also counter the point that aiming at a common set of features would impact the ability to innovate. Innovation is not stifled by a common set of features, how you implement these features for your end users can lead to innovation and set you apart as a commercial entity. Also the ability to add to that set of features in a standardized way only adds to this case

I would even argue that having some global identity (whatever that would look like technically) that would be federated will make people realize that they still have choice, but that through federation you can connect people in new ways. For example my friends on WhatsApp that don’t want to switch to Signal could hypothetically talk to me if some federation was setup between them.

TL;DR We’re not the first ones to do this and we should take learning from protocols like XMPP who have done federation for a long time.

More than 6 years back I wrote why there is no need for federation among WebRTC-based apps. I had even developed an app platform with these thoughts in mind -EnThinnai. You can explore it live in a showcase instantiation - mystoop.chat.

https://blog.enthinnai.com/2013/07/25/who-needs-federation-in-webrtc/

Welcome @aswath, great read and I think you make some excellent points about the lack of federation and why that is the strength of WebRTC, I hadn’t thought about it in that way yet.

I agree with your assesment of WebRTC in that it doesn’t need federation to be able to setup a session between two parties with a simple HTTP request which is amazing already. I personally think that the federation we need is outside of the scope of the WebRTC protocol, let me explain.

I think that some form of federation would be beneficial for mainly identity (is the person you’re connected to who they say they are?) and ‘user discovery’. (how do I find my friend?) Yes you can just give someone a URL and they can setup a session with you, but from a usability perspective I don’t see people sharing their own links for people to contact them. If you took some identifier, let’s say an email (user@example.com) you could share this with your contacts. The ‘example.com’ service could then also offer some identity service which could be queried by other services, basically turning it into a federated contact book.

So no I don’t think the WebRTC protocol needs federation but to make it usable it could benefit from a layer of federation to add extra services to it.

Yes, in our system we are using HTTP URI (Indieauth and possibly WebID) as the ID with the HEAD section carrying the app server info. We allow unregistered users to initiate a chat session with registered users. These unregistered users can use their email id, which is then authenticated using Indieauth. We have deliberately stayed away from using email kind of identifier, since it is not portable from one app provider to another. (You can read more details at https://blog.enthinnai.com/2019/10/03/user-id-what-is-it-and-why-is-it-different/). In our model, the calling user always pings called user’s server to connect to the called user and since both the users have verifiable ID, the app server authenticates both before connecting them.

We do expect the called user to have “shared” what we call “Call URL” with the calling user. It could be placed in a “Call me” link pasted in a page, email signature and the like. Not only that, this Call URL is not a static one; it could change from one place to another so as to carry the contextual information. You can read more details at https://blog.enthinnai.com/2019/10/03/how-can-my-friends-contact-me/ and https://blog.enthinnai.com/2019/10/03/context-types-and-their-use-cases/. I think you will agree with me that meet your requirements and provide additional functionality that only URI-based scheme can provide.

Just read through your blog posts and read up on the IndieAuth spec, interesting stuff you’re working on. I do have some questions/issues with the way you portray the email vs. HTTP URI identifier.

I have to disagree here, unless the end user owns the domain both a URI or email tied to a domain not in your control is not portable. If a provider decides to close down/ban you/deny services in your location etc. you lose that online identity and people will be unable to reach you on it. For example you use twitter for your WebRTC identity but due to some political tweets that twitter does not like they decide to delete your account, which renders you unreachable.
A telephone number is a bit more robust in this regard as it has the distinct capability of being able to be ported to other providers, thus not being stuck to one (app) provider.

In a distributed/federated model you can sidestep this problem by having some unique identifiers. Yes they should probably be independent of provider (so using user@provider.tld would not be great) but this leaves the problem of user discovery unsolved, how do you find the URI to connect to if you don’t know which server to ask? I don’t have any answers here, just more questions really :smiley:

But I do have the answer. I may not be articulating it clearly, but I do have the answer; after all I have been sitting under Bodhi tree thinking about it for more than 13 years now (yes even before WebRTC). :-0

I was not thinking of email portability, but app provider portability. So when I give you my reach info, I need to give you my id as well as the app provider. If after sharing the info with you, if I change the app provider, then I need to contact you and update the reach info. By the way the JabberID, Matrix ID and Mastodon ID all have the same problem.They are all isomorphic. (I am tacitly assuming that we all individually own our own domain name and so can map the canonical email id to the real provider.

Contrast this to an Indieauth based ID. Since this is indeed a web page, we could agree to convey the info on the app provider in the HEAD section. This means I can change my app provider after I have shared my ID with you, I can change the app provider without impacting you, since I can change the app provider info in my ID page. There are some additional benefits to the user. The identifier, the place where the page is hosted, the authenticating end-point and the relying party can all be independent of each other. So it gives the user freedom in selecting and changing the host without changing the identifier itself; also user B can authenticate user A, using its own authenticator.

I may be misreading your point about Twitter as being my identifier. I am not suggesting it. My own web page will be my identifier. Yes, it could contain email, Twitter, Github and PGP info so Party B could use them in conjunction with Indieauth to authenticate me. The first three components are useful to ease the onboarding process for new users; as you mentioned, depending solely on Twitter or Github could shut you out. Use of email is less problematic, but could be an issue. Personally, I prefer to use PGP, but may take some time for it to be generally adopted.

Finally let me address your question regarding user discovery, determining the person’s application server. My position is that there is no need for a single solution. The first thing to note is that in a WebRTC system the way I reach you is starting with a HTTP GET. This is contrary to what I think Ole claimed during the discussion. I think he is mistaken. The second is that for you to reach me, you do not have to be a member of the same or even another WebRTC system. The third is that while trying to reach me, you can easily go around your system if that is beneficial. Given that there is no need to have a single scheme, let me describe how we do in our system that we think is the most beneficial to our users.

We recommend that users place a link in the ID page that visitors can click to initiate a session. Additionally, in our system the link that will setup a session can be deduced once the user’s ID and the server is known. So your browser through a javascript routine can easily compute the call URI given my identifier. Finally, users will be including call URI in multiple places, like email signature, blog posts and the like. Wherever you would place phone number or email address, you will be adding your call URI. Please take a look at my ID URI for a working example - id.mystoop.chat/id/aswath.

2 Likes

I do not doubt your ability in the slightest, the questions and responses I’m giving come merely from a lack of understanding on my part. :blush:

That being said, let me start by approaching this from a different point of view. In terms of technology the system you’re describing (and have built) is very impressive to say the least and I do not doubt that it works in a way that it doesn’t need federation to function. I agree on your points about Jabber, Matrix and Mastadon have the same ID problem.

The problem I have is with the use of a domain as your ‘global identifier’. I don’t see how it is any different than using let’s say twitter, facebook or github for the same purposes. Most people don’t own their own domains, nevermind know how to deploy a WebRTC server and setup DNS correctly. The solution you have is really cool but in order for it to work as intended (non federated WebRTC independent of provider) everyone would need to own their own domain or have to resort to use an app provider (like yourself) to make it work.

Correct me if I’m wrong but it feels like because of this limitation (people not owning their own domains/servers) you’re back to needing to have an intermediary provider and are therefore not much better of than having a facebook/twitter/github as your identity.

Let me first hasten to clarify that my impetus remark was meant to be funny and certainly not meant to tower over you. That is not me at all.

Now to the points at hand and let me take one at a time. You are right that my Twitter/Facebook/Github handles could be my identifier. Except there could be a practical problem. Since the architecture calls for my server to authenticate you before you can initiate a session with me, my server must use OAuth procedure towards Twitter/Facebook/Github. That means my server must have OAuth permission with these providers. Use of IndieAuth eliminates this requirement because they have established this permission and they act as my agent. But unfortunately in the current implementation, they are not allowing direct use of Twitter/Facebook/Github identifiers; instead they are requiring an indirection. So let us agree that theoretically it could be used. But if one pays the price for their own Web address, then they get the freedom to migrate between any of these base id providers. Furthermore if they are comfortable with the use of PGP, then they do not have to depend on any third parties and their activities will not be mined.

Before I take up your next point, may I request your indulgence to fill in any gaps since I may not have formulated my argument efficiently. For the moment, let me pin your remark on owning a DN and operating a server. Otherwise, will you grant me that “unfederated, but federated” system is preferable? For one, it does not require you to own such a server to initiate a session with me; secondly there are no requirements on our servers to be compatible and federated (administrative nightmare that I had talked about). Let me submit that getting a DN is not an expensive proposition and itcan even be free if one is willing to settle for a second level subdomain. (There are some purists that take exception to the use of assigned DN at all; I do not have an answer for them.)

The server itself has very minimal requirement. The current app can be run on a Raspberry Pi Zero and can be hosted from ones own home. I am saying this for only effect and will be the first one to admit this is not generally workable. Most consumers will prefer that somebody will be hosting it. But such a hosting is a commodity service. Just like I am hosting my blog at a third party provider and can move from one to another without much difficulty, I could do the same here as well. So once I have a DN and a server that is hosting the WebRTC app, hosting amy ID page in the same server comes for free.

I hope I have moved the discussion forward and not boring you. I myself am enjoying this discussion. Cheers.

No worries I didn’t take it in that way at all, I enjoy having this discussion without invoking Godwin’s law, haha. :smile:

I agree with your first point that you would need to setup an OAuth app to communicate with third party providers like GitHub and that this poses a barrier. IndieAuth is a great solution for this, but again relies on the user owning a domain/knowing how to setup the WebRTC server. I do agree with your second point that “unfederated but federated” is preferable for the reasons you mentioned.

The thing I think we disagree on is the assumption that people will want to bother setting up a domain name and server or having someone else host it for them. On that first part I want to say that while I agree it’s financially feasible for people to own a domain name, a big majority of those people would not even know what to do with it. This point is important in my eyes as it greatly bring the adoption of this technology into question. If there’s nobody using this technology then it will stay in the realm of “cool technologies that are only ever used by ‘nerds’” (I think PGP is a good example of this). Mind that this does not say anything about the technology itself however, I’m just pointing out some flaws in usability that I think will be very difficult to overcome.

On another note I feel that having someone else host your identity defeats the whole purpose of being able to switch providers as you wish. If you want to change domain names, for example going from free hosted subdomain to your own domain, you run into the same issue where you just lost your online identity and have to manually let all your contacts know you’re now using that new domain.

I think we have reached a common agreement on the benefits and feasibility of my proposal. I can characterize the remaining issue to be market need and viability. The fact that I have this available for more than a decade with no traction makes me not take up that point. Till I make some impact in the marketplace, I am relegated to my soapbox and nothing more. Though I murmur to myself, “But then people all the time complain about Facebook and this technology can be used for social sharing of content as well.”

On the point of domain name, let me imagine an organization like Mozilla or EFF issues third level DN to their donors. Given the negligible cost involved it is feasible. Then a simple domain forwarding can handle the scenario where one wants to graduate from third level DN to second level one.

I don’t think I have anything further to add to this discussion, except to draw your attention to Soild/WebID (https://solid.mit.edu/; https://www.extremetech.com/extreme/281334-tim-berners-lees-solid-project-can-it-save-the-web). Probably, Tim Berners-Lee would be successful where I have not been.

Thanks once again for patiently engaging with me.

1 Like

It’s been great discussing this with you, I would buy a front row seat to your soapbox opera any day of the week! :slight_smile: I feel like what we’ve been discussing is definitely the right way to go technology wise so there’s no discussion there. What it would need though is some bright UX/UI and business minds to think about how to bring this to the crowds.