Federated conversations about spreed HOT 50 OPEN

Well at least we got a response now, finally. Still no on-topic response though, which kinda proves my point.

I never said it was going too slow (thats a strawman argument, while you ignored my prime argument "Lack of communication".

If you want more communication, go and do it.

FROM THE Maintainers. You know, the dude flagging stuf for a certain release. How can I communicate the plans, roadmaps and wishes of someone I am not?!

I'm not asking for more communication tools, i'm asking for actually responses to community concerns.

Let me quote your earlier message.

• What are the goals (or preferences) for Talk: Expanding your framework to include federation and such (https://xkcd.com/927/), expanding the current framework to support multiple frameworks (like some social apps are playing with) or Moving to another framework (Matrix, XMPP, Matermost)
• What is the pseudo-timeframe (months, about a year or a year+ ) to have enough features to call it "feature competitive" (in comparison with other frameworks) when it comes to communicating outside a single server instance?

Clearly, you assume there is some hidden agenda, some hidden feature plan. But we don't have that. We're 100% transparent, which interestingly seems to be your issue.

It might be hard to imagine, but we work so transparent, you can see our release plan here:
https://github.com/nextcloud/spreed/milestone/37
and here is the full plan for the release after that as it currently stands:
https://github.com/nextcloud/spreed/milestone/43

Anything on there has no time plan. Or feature plan. We simply haven't had time to think about it. So we're not lacking communication - we're 100% transparent: there is just as much plan and decision as you can see. If that is not enough, well, we're back to: not enough time to do it. Go and do it if you think you have a good approach. Make a proposal, gather feedback, go implement it. That's what any of us would do if we decided it had to be done.

We're not IBM, we don't have a product manager spending all day making pretty diagrams of feature plans and roadmaps and stuff like that. We just do the work in the open.

@jospoortvliet
Considering there are also actuall PR's waiting for your (= maintainers) response, lack of communication is a more general issue. Not limited to Issues.

That is also a lack of time. We get pressure from customers to fix things asap. Our priorities are very transparent, too:

• customers go first
• then community PR's and features for next release (see issues and milestones)
• then everything else

TLDR:
I never said development is going slow. I'm saying you guys (the maintainers/project leads/whatever) have trouble communicating with the community if you guys don't fancy a certain feature yourself. That goes for both PR's as Issues.

The Public Relations suger coating of bad-faith or incompetence at times, was for me the reason NOT to spend time making a PR for certain features. Maybe one reasons there aren't people doing things is partly the Nextcloud communication style. (i'm not saying it is, but your argument works both ways)

There is nothing more. No hidden communication, nothing is missing. If we don't say "we're working on it right now" but say "we want to do that some day" then that is literally all we know. There's no more secret plan and timeline we are not sharing. We're not big on meetings, big plans, stuff like that. We work in the community. There are a few things we agree to work on before a release - issues are created and we start working on them.

You ask 'what is the plan for federation' and ask a timeline. Well, there IS NONE. There is not a 'secret timeline', there just isn't one. We will work on it when, at some point, we (as in, whoever works on Talk, that includes community members who contribute) get together and say to each other: "gosh, it'd be nice to have that for the next release". And then "who wants to do it?" And if then somebody puts up their hand, again, volunteer or paid doesn't matter, they get it assigned and it gets into an issue and goes in the milestone. And that's it.

Until that happens, anyone can do it - and that person should be transparent, too. Just say on the issue you go work on it. Create a PR. get feedback, improve, review, merge.

Then there will not be a clash with a secret plan, I guarantee you that. Because there is none. And if there was, we'd be stupid because that would be bad for transparent collaboration.

So again, if you are holding back contributing because you wonder if the contribution will be denied because it clashes with some big secret plan - don't bother, there is no secret plan.

Edit: sorry for the repetition but it is a bit frustrating to have ppl complain about a lack of communication when it is all 100% here in github...

Sure, we keep a nice feature list of what is coming in the next release written in pretty text secret - for marketing reasons. But you can make that list yourself the way I make it: go through the closed PR's in the mile stone. And I made that text yesterday - not 6 months ago when a secret cabal was planning for the Talk 9 release... Because, guess what, no such cabal exists.

from spreed.

I think now is the perfect time to take further look at this! Please implement the federation function 🙇‍♀️

from spreed.

This is such an important feature for Talk because it enables people with their own Nextcloud systems to chat without the need to invite a guest using a public link or creating an account on the other system as well as preserving the chat log with each Nextcloud instance that is taking part of a call.

from spreed.

So I just read through this and I feel like this HAS to have come up SOMEWHERE before but... why not just integrate Matrix as the comm layer for Nextcloud? They're already doing a really good job at making federated slack-style chat with voice and video (by integrating Jitsi.. this is a thing ;).)

It would be much more the 'unix way'. I feel that 'elegant integration' is better than 'monolithic bloat' (the most frequent criticism I find about NC in reviews lately). Also, while lacking the coding expertise to say for sure, I really feel like NC devs coding an integration would be an order of magnitude less work than coding from scratch. I'm thinking here about how NC devs collaborated with LibreOffice devs to bring about Collabora as an OPTIONAL INTEGRATION rather than trying to 'write NC office'.

from spreed.

So the enterprise backend is open source now: https://github.com/strukturag/nextcloud-spreed-signaling

from spreed.

If your goal is a "go-to solution" for federated communication between business, you can't tie such a thing to a single implementation. As much as we all like NextCloud, it needs to be possible for other projects to also support it which means it needs to be openly documented, and ideally openly developed too.

Such standard protocols already exist, Matrix and XMPP being great examples with numerous existing implementations. Projects such as Movim (also written largely in PHP) are good examples of this approach.

In reality if NextCloud grew a nice clean documented API for federated chat, Matrix and XMPP would probably grow gateways for it pretty easily.

from spreed.

#2560 has been fixed and is a step forward on this huge topic.

from spreed.

I'm trying my best not to troll this issue, but I really don't grasp why you'd reinvent features such as federation and history sync (which are anything but trivial to get right) rather than building on top of existing solutions which already solved these and other problems based on open standards.

from spreed.

Why not using the open source protocol Matrix to federate between servers?
It would make Nextcloud Talk integrate the Matrix network (increase both value of Netxcloud Talk and Matrix) and would solve this issue at the same time #809 .
Would it make Nextcloud Talk the best matrix client? Could be :-) some people will get that feeling.

from spreed.

Federating chat would be the go-to solution (besides Matrix) to re-think communication in larger enterprises and non-profits with complex organizational structures. Talk being able to have consistent, non-guest chats between different Nextcloud-Domains would basically end the stupid "What messenger to choose" conversation. For most people, Chat-Ops and all the stuff Slack does doesn't really matter. But being able to talk safely and first and foremost with low entry-barriers with other people also believing in Nextcloud being the best thing to run when it comes to data privacy - that would make a severe difference :) And it would help to migrate people to the platform. Chat is currently the only thing that's not living up to the decentralization-ideal. So just a bump to not forget this. Maybe this can be solved by integrating with Matrix as the underlying protocol and then just bridge with Talk internals.

from spreed.

Federated Chat would bei awesome!

from spreed.

uhhh... I'd like to use that feature!

from spreed.

Let's hope this feature might be included in Nextcloud 26 and one of the best features announced at the NC conference.

from spreed.

Curious as to the progress/potentiality of this being integrated? What realistically would be necessary in order for it to work? Could a third-party integration (something akin to a security-hardening add-on like Google Authenticator or another TOTP provider for 2FA) plugin, setup strictly on a domain meant for linking participating separate nextcloud instances (i.e. nextcloudcalls.com or something like that) and write a script that generates an one-use authentication token upon the request to communicate via the video chat plugin? Kind of a trusted middleman service that facilitates the connection requests between the participants in a video or voice call. Would have to be something that kept the connection ultimately between the actual end-users' nextcloud servers themselves obviously.

There's a bunch of existing frameworks for videochat/voice chat, videochat + text-based chat simultaneously that shouldn't be too difficult to look into in terms of what might be best used to integrate into the existing architecture. Admittedly, I only recently deployed my own nextcloud server and have only had a few hours over the past couple of days to poke around the code. Been mostly busy setting up the essential stuff, and of course, transferring over a ton of files and obsessively setting up the filesystem/folder structure.

Anyway, just some thoughts. Will take a look on the nextcloud forums as well, perhaps I shall see some of you there (I'll have the same username) Cheers 👍

from spreed.

Notifying the developers with pushing replies without new content will not help to get it in faster.

@nickvergessen
Same could be said about responding without anything to go with as a developer.
People tend to get worked up about that and that causes people to go push for more info.

But trying to be somewhat constructive:
Considering your last flags (next major (19), Following Major):

• What are the goals (or preferences) for Talk: Expanding your framework to include federation and such (https://xkcd.com/927/), expanding the current framework to support multiple frameworks (like some social apps are playing with) or Moving to another framework (Matrix, XMPP, Matermost)
• What is the pseudo-timeframe (months, about a year or a year+ ) to have enough features to call it "feature competitive" (in comparison with other frameworks) when it comes to communicating outside a single server instance?

I'm going to be fair:
People are willing to sacrifice some features, if it means heaving everything under one roof and in some cases the solutions others provide may be too-much out of scope (such as bitwarden when it comes to passwords, a totally different philosophy).

But for talk, users (including corporate) basically want: Mattermost (light) with federation.
Mattermost has great plugin support for other protocols but (also) just lacks federation itself.

If you guys get both of those two functions working: connectivity and federation, Nextcloud Talk would push itself to the top-part of the communication suite-pack.
Those are not easy features code wise and hard to do solid. But if you can, you're in... if you don't it would always stay a "meh" niche solution.

from spreed.

The software if fine though, just waiting on a more community based fork, with a more communicative leadership.

Why wait for a "more community based fork", instead of just starting to be part of the community and send a PR. We are totally open to have (even base only) work done by anyone to help moving this forward.
But at the moment we are more focused on the "single instance" use cases as they currently pay our bills.

They are only interested in features/fixes they fancy and it seems it has more priority to put documentation behind a paywall than to develop actual software.

In the last weeks we did a lot to improve the calling performance and experience which helps everyone. The documentation is not paywalled but can be found here: https://nextcloud-talk.readthedocs.io/en/latest/ the only thing missing there is how to configure the High-performance backend which needs to be purchased from our partner. For everything else it's just "there is currently no documentation". But also there you can help and get it completed, by sending a PR to https://github.com/nextcloud/spreed/tree/master/docs

from spreed.

Well at least we got a response now, finally. Still no on-topic response though, which kinda proves my point.

I never said it was going too slow (thats a strawman argument, while you ignored my prime argument "Lack of communication".

If you want more communication, go and do it.

FROM THE Maintainers. You know, the dude flagging stuf for a certain release. How can I communicate the plans, roadmaps and wishes of someone I am not?!

I'm not asking for more communication tools, i'm asking for actually responses to community concerns.

@nickvergessen
I missed it, so you removed your "paying customer only" docs like integration with certain authentication schemes? Or do you call that "High performance backend"? (I don't think so, because it has nothing to do with performance) in that case: Thank you!

@jospoortvliet
Considering there are also actuall PR's waiting for your (= maintainers) response, lack of communication is a more general issue. Not limited to Issues.

TLDR:
I never said development is going slow. I'm saying you guys (the maintainers/project leads/whatever) have trouble communicating with the community if you guys don't fancy a certain feature yourself. That goes for both PR's as Issues.

The Public Relations suger coating of bad-faith or incompetence at times, was for me the reason NOT to spend time making a PR for certain features. Maybe one reasons there aren't people doing things is partly the Nextcloud communication style. (i'm not saying it is, but your argument works both ways)

from spreed.

I missed it, so you removed your "paying customer only" docs like integration with certain authentication schemes? Or do you call that "High performance backend"? (I don't think so, because it has nothing to do with performance) in that case: Thank you!

Are you talking about Nextcloud Talk docs or Nextcloud server docs? I can only talk about Talk and we don't have any fancy authentication schemes that were removed.

I never said development is going slow. I'm saying you guys (the maintainers/project leads/whatever) have trouble communicating with the community if you guys don't fancy a certain feature yourself. That goes for both PR's as Issues.

As for PRs: 0 (zero) community PRs where delay to the next major version so far, they were always merged for the next release.
As for issues: I'm always moving this issue when milestones get the version assigned. I could of course every time also leave a comment "Since no one picked this up, I'm moving it to the next major", but I think it is not really useful to have empty content-comments like this.

See the list of milestones in the readme: https://github.com/nextcloud/spreed#milestones

💛 Following Major - The following major milestone is for issues/PR that should be worked towards/on but didn't make it into the next major due to timing constraints

And also see the note at the end of the milestone list:

You can always pick a task of any of the milestones and we will help you to get it into the assigned milestone or also an earlier one if time permits. It's just a matter of having an overview and better visibility what we think should be worked on, but it's not exclusive.

So yeah, our communication might not be good, tell us how to improve and I will try.

from spreed.

So the enterprise backend is open source now: https://github.com/strukturag/nextcloud-spreed-signaling

More about that: https://nextcloud.com/blog/open-sourcing-talk-back-end-rc-of-talk-9-brings-lots-of-improvements/

from spreed.

Yes, thanks for your comments, we know the usecases for federation.
You can also upvote existing comments or the initial post.
Notifying the developers with pushing replies without new content will not help to get it in faster.

from spreed.

Why wait for a "more community based fork", instead of just starting to be part of the community and send a PR. We are totally open to have (even base only) work done by anyone to help moving this forward.

Exactly. This is a completely open project and anything that goes too slow or doesn't fit the needs of people is simply because we can only do so much... If you want more communication, go and do it. If you want work on Federation to happen, go do it. If we were BLOCKING people from doing things, sure, a fork is a good idea. But we're not - we just don't have ppl to do it...

from spreed.

I give +[lot] for imagine matrix behind Talk.
It would be wonderful to have one client for all channels, inside or outside our NC, both on desktop and mobile.

But what about the integration of all the other NC apps ? Can we imagine a painless links of files, deck and all other for the groupware use ?

from spreed.

This is great to see! Once implemented would federated messaging work as well?

from spreed.

Talk federation chat / calls would be awesome

from spreed.

@ata-star I think developers not responding to my 2 very clear, constructive and fundemental questions (and giving the same lac of effort to a lot of other issues), is pretty clear.

They are only interested in features/fixes they fancy and it seems it has more priority to put documentation behind a paywall than to develop actual software.

I've since stopped caring what Nextcloud does, it does what it wants but just don't expect them to care about community. The software if fine though, just waiting on a more community based fork, with a more communicative leadership.

from spreed.

Is there any progress on this issue? I could help implement this feature since I'd really like to use it 🙂 Get in touch, cheers

from spreed.

Talk federation would be needed because of external contacts.

from spreed.

The people over in Matrix land work on a protocol for group calls involving multiple servers. There is a document and a talk explaining the details. Not saying that this is the way to go, but it may give some inspiration.

from spreed.

In the last weeks we did a lot to improve the calling performance and experience which helps everyone.

I can confirm that. The last 2-3 minor talk updates of major version 8 boost the usability a lot!

the only thing missing there is how to configure the High-performance backend which needs to be purchased from our partner.

Well, I understand that nextcloud tries to earn some money. And this feature targets buisness companies (multiple audience video chat). So I'm okey with the current situation.
But for the future, my hope is this project: https://gitlab.com/powerpaul17/nc_talk_backend/

Yeah, and the federated talk was always a must-have feature and talk possibly would never have been released without this feature.
And one anoying thing is, that you advertise this feature for the future for a long time until now in the README.md.

from spreed.

Is anyone already working on this? Is there any information/discussion except this issue? It seems to me a very interesting task and I would like to participate in its development.

from spreed.

So did this come in Nextcloud version 20? I've heard conflicting things so I'm not exactly sure.

from spreed.

+1 for federated messaging, calls and all the other good stuff!

from spreed.

This feature will be indispensable to a federation. Organizations can split up their servers by region yet have them all tied together in communications. Is it not in essence a binding to the user list at play here? Federated servers swap that data so it should be available to Talk. Really WANT this feature - kudos to those pushing for it. 👍

from spreed.

I am thinking about using Chat in a Slack-style fashion - it then becomes very important to be able for an invited user to pick up from before and have unique ID on ongoing conversation.

from spreed.

XMPP in PHP is far from trivial, but you can be sure it is one of the options on the plate while looking into this.

from spreed.

See headless ConverseJS for convenient Javascript only XMPP client library.

Movim.eu codebase might also be a good place to look for relevant php based XMPP code as it implements most of Talk's wanted features such as federated calls over XMPP / WebRTC.

from spreed.

@teotikalki collabora is a memory nightmare. for every document which will be opened, a new libreoffice is opened in background. that's something no one wants to have on its rpi.
in onlyoffice everything happen in the client side. and onlyoffice is not written bei NC itself. onlyoffice is a different company which has build this open source office suite and what is sponsoring its integration.
so at the end you have the choice between collabora and onlyoffice - both is open source and not made by nextcloud.

but in case of nextcloud talk - a agree.

from spreed.

Status?

from spreed.

So?

from spreed.

We are currently not actively working on this task, but there are a lot of pre-requirements which need to be handled. We need to be able to post messages with cloud ids as users, their display name should somehow be kept/updated as we go, etc.

from spreed.

This issue is still open, so it's not in.
You can link up multiple conversations with the matterbridge, but that is not really federation, as files and mentions and ... All doesnt work very federated

from spreed.

You can link up multiple conversations with the matterbridge, but that is not really federation

bridging conversation works fine. An yes, it's a workaround.

but there are a lot of pre-requirements which need to be handled.

True. But is there already a list of pre-requirements? Such as

• sharing files/folders/cards/ ... etc
  • maybe that's one of the easiest part? everything that is shared with the conversation, is shared also with their participates user id or federated cloud id (when the user is not a local one).
• handling calls
  • that might be difficult, because the spreed backend setup might be different on all instances. some may have a coturn, some the high performance backend ... here a convention can be: the user which is starting a call, whose instance infrastructure (spreed setup) is used.
• ...

I am trying to say that the work only starts when the discussion about the requirements has been made and all the things that need to be decided are done.
Am I wrong?

from spreed.

👎

from spreed.

hello, any news in this section ?
I would to create federated conversation... NCTALK between two servers. (server have trust between)
but dont know how to start. i try with matterbridge nctalk, but no success.

from spreed.

Hi guys,

How do I build this project? I've downloaded the source into my custom_apps folder of my NextCloud instance. Do I cd into the custom_apps/spreed folder and run npm install followed by something else?

Thank you,

Chris

from spreed.

If you just install it from the appstore you don't need to do anything:
https://apps.nextcloud.com/apps/spreed

If you want to work on it and develop, see the readme for instructions:
https://github.com/nextcloud/spreed#development-setup

from spreed.

same

from spreed.

I have no backhround im this whatsoever, but if I can somehow help to implement this I would be very glad to do so, I believe this is a very useful feature.

from spreed.

There seems to be some activity here. Any progress? Any help needed?

from spreed.

Does the missing interoperability of talk/spreed across federated instances mean, that users in a Global Scale environment cannot chat and call each other?

from spreed.