| Summary: | Extending Falkon capabilities with XMPP, SamePlace, and WebXDC | ||
|---|---|---|---|
| Product: | [Applications] Falkon | Reporter: | Schimon Jehudah <sch> |
| Component: | extensions | Assignee: | Unassigned bugs <unassigned-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | nate |
| Priority: | NOR | Keywords: | accessibility, usability |
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | All | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Schimon Jehudah
2025-06-09 03:44:10 UTC
Hello! You've reached the KDE bug tracker, which is for reporting bugs or requesting new features. But requesting multiple features at once in the same ticket is problematic, and it's not really the right place for "make everything different in a vast overarching way". So I'm afraid this is not an actionable ticket, sorry! Nate. Thank you for your respond. I disagree. The ticket advises to create a new extension to interact with other people, as SamePlace does. However, SamePlace works with Pale Moon and other XUL based software and relies on centralized servers, whereas WebXDC does not rely on centralized servers. Hence, my ticket is valid for consideration and discussion of a viable implementation of that idea for Falkon. One of the extensions which I created for Falkon is a buku extension, which can also be realized for XMPP, as referred https://github.com/jarun/buku/discussions/772 Further more, I have created a forum post for utilizing XMPP as a **standard** synchronization platform, and I have yet to receive a respond. https://discuss.kde.org/t/xmpp-as-a-platform-to-synchronize-data/26688 Please. Consider to reopen this ticket. Thank you. I'm afraid this is one of those thing where if you want to make it happen, you're probably going to need to take initiative to do it yourself. The scope of what you're requesting is simply too large to be tracked in a Bugzilla ticket. Fair. Then, may I open several tickets, of which title starts with [XMPP]? If each one is narrowly-scoped and actionable, yes. However keep in mind that Falkon is a project without a lot of development resources, so it's still almost certain that none of these ideas will ever be implemented unless you are the one to do it. :) Yes. Of course. The ticket could be utilized for discussion as well, and consequently to coordinate efforts. Thank you, Nate. Created issues that involve of XMPP. Bug #505383 Bug #505385 Bug #505386 Nate, may we please have a new keyword "xmpp"? I don't think so; it's too niche, and keywords are global in scope. XMPP is not a niche. XMPP is the internet which big organizations try to conceal in favour of a perverted HTTP which is saturated with ECMAScript (i.e. JavaScript) to harvest our information, and our kids information, and is designed to keep us frivolously engaged. However, XMPP is similar to HTTP, just better, and it is easier for you, me, and even out kids and grandmother to utilize XMPP, provided that we have the proper means to engage with XMPP. From an article of Mr. Jack Moffitt. > How do we survive without them? Here are some of the ways: > Web frameworks may offer a lot of functionality, but XMPP has a excellent, diverse set of extensions that offer a higher layer to application developers. Web frameworks are still essentially stuck on basic protocol plus ad-hoc commands. XMPP provides pubsub, presence, discovery, and much more. > Communication is done via XMPP through Strophe instead of polling a database or using work queues. This is a step up in efficiency. > Configuration is stored in pubsub nodes instead of relational databases. One awesome consequence of this is that all subscribers get instant notification of configuration changes, sort of like a broadcast SIGHUP. Front end apps, administrative code, and internal utilities are all just JavaScript. This makes them trivial to develop and test locally, and we don’t need any special deployment code. > The whole system is more decoupled because there is no middle interfacing layer. The backend speaks XMPP, the frontend speaks XMPP, and they both use standard XMPP layer protocols to do work. Source: https://metajack.im/2009/01/25/we-dont-need-no-stinkin-web-frameworks/ Involving XMPP in our software, not for messaging, but for storage of information is something that we all need, from publishing of information, to push notifications, to synchronizing of data. For what it's worth, XMPP can be even utilized to synchronize Linux installations. I did just that for a VPS company, of which I was a legal counsel of, after the manager feared of utilizing BitTorrent and IPFS for that purpose. XMPP more than messaging. Forget the messaging part of it, and concentrate on the stractural sense of XMPP. Hence, please consider to consider XMPP as a keyword. If there's interest more broadly throughout KDE, we can consider it. Until then, the [XMPP] prefix that I see you added to those Bugzilla tickets should suffice. Nate. Thank you. I have sent to you a direct email message titled as "KDE and XMPP". |