Hi @how , thanks for taking the time to critically engage with the topic and share advice and further readings. That’s all very helpful!
You are right, that the given presentation leaves a lot of questions unanswered, I’m currently working on and aiming to publish in the next weeks a way more detailed documentation. In the presentation i wanted to give an overview across the topic. Seemingly it wasn’t conveyed this way. It may have seemed like the topics i skipped for keeping the presentation short are details we in the project haven’t addressed at all. That’s already a great learning for us on how to explain our goals and scope.
Now for some of the points directly:
What is interconnectivity for us: You said it’s technically not really defined. True! It’s a concept for which the exact technical definition needs to be found for each use case, we are defining the technical definition for it on the use case diverse social networking.
What is the concept? Let’s do the example of Matrix and XMPP you brought up.
If Matrix and XMPP will manage to get their bridges going and have full interoperability, great. For all the cases where they don’t, they should agree on a common minimal interconnectivity standard and mechanism, to ensure user communication. Whatever that is in their use case, needs to be found. For instant messaging there might be a different approach meaningful than the embedded experience we are pushing for in diverse social networking.
So there is no problem with cross-protocol communication, because the very approach is to define a common interconnectivity protocol, which can be used for the use cases where the cross-protocol interoperability is not given.
My belief is that the protocols themselves require rethinking. If they produce incompatible applications, they need rework. Since applications implementing a protocol should not need to worry about compatibility, thats what the standard is for. If AP, XMPP, Matrix.org want to build for use cases where communication islands are acceptable, thats alright. If they want to produce open communication, they should come back to a table together and see, how they can guarantee communication, even if the other system is implemented in a different way. I understand these systems each want to address different aspects, but i believe when communicating in-between, they should allow to drop those aspects. Otherwise they are advancing more their own technical beliefs, than actually producing value for the end user.
What will happen in the future - if some of these protocols add a new interconnectivity layer into there own structure, if only some instances will add an interconnectivity module to their architecture, or if no one ever cares about this approach - i of course don’t know.
Engagement with W3C, IETF: I do see these institutions as the go to places as well. As you rightly guessed, we’ll aim to engage with these working groups, once we have further progressed! Until then my goal is to lurk into different communities, find people engaged with the topic and learn about different views. You’ll find a proposal from me towards the W3C interop group soon. I’ve followed your proposals there, but did not engage in the discussion yet because i do want to address this body, once we have our written documentation.
Whom to bring to the table and which table: I believe it needs a standard for interconnectivity. Those who need to implement it, should get an invitation to the table. What table that is, if it is an iconet, W3C, IETF, or any other table, i don’t really mind. For me it’s not about putting my label on things, i just want to support the process.
Global addresses: These where examples for addresses in a shared interconnectivity standard! What’s needed is a global and a local part. Global needs to have a defined structure (here dns), so it’s clear where to deliver packages to. Local can be whatever, the one system does not need to understand how the other system maps a local part to their rightful user.
Consistent user experience: Hereby i mean that users do not have to understand, from which applications they can reach which other applications, and which protocol they are using. I do agree that we do not solve consistent user experience on a front end layer, i should probably use a different term to describe what i mean there., maybe consistent availability.
License & openness of the project:
Since you last raised the topic, we have contacted the FSFE-legal team for help, they have not had the time to get back to us yet. The difficulty is the following: Our prototype development uses rdf-pub as a first context, which uses eupl, a copyleft license. So our interconnectivity module into that project will also be under eupl. If we now will built another interconnectivity module into another context, which has another copyleft license, i’m not sure if conflict can happen. When we have figured out those details, we’ll be more vocal about our license usage, i just want to do it right.
If i’m looking for an exit? How would the open communities ever use and implement on top of a standard for interconnectivity, where i have a corporate thumb on it. That’s not at all the plan, but i do respect your healthy distrust. We updated our impressum. You’ll find our bylaws where we state that all knowledge and advancements we produce or gather, are made available to the public for free. That’s the legal basis for our non-profit on a research promoting basis. I understand the details are also important, we’ll get there.
The usage of ̷̑͜F̸͛̿͜á̴̜͍k̶̡̺̃̈́e̵̲̬̎b̶̹̄̏o̵̖̾͘o̶͘ͅz̴͉̺̈́̀, insta, youtube etc.: I do agree with you and value your honest feedback! It’s a hard topic, also in our team we’re split about it. I actually am on your side there, i don’t really want to promote these links on the webpage, but currently the majority of our team thinks that they add more value than harm. I’m happy you shared that this lowers your trust. I hope we can rebuilt trust with meaningful contributions.
On your answer on what’s needed process-wise:
I love these inspiring words. I want to do my best to grow into the direction you have laid out here. What helps me is to know that i’m not alone on that journey.
Again: thanks for being so critical, that helps me a lot. I hope the explanations i added here helped with some of the things which remained unclear.
