capability of starting without dbus installed

The Problem

D-Bus is commonly known for being a poorly designed medium for IPC if not an insecurity at worst given it allows anyone the same level of access over WAN as your local user

With the notion of dbus being an insecurity at all, I've personally preferred to just not have it installed to begin with I personally don't mind the lack of IPC, in fact I prefer it

The Solution

while KeePassXC and other keyrings are nice, they shouldn't be a requirement

locally encrypted files should be an option for going that extent and there should be an additional password at minimum if the user prefers this practice (I know I'd enable it) but by default, this security should be a disabled option with a warning your data is not locally protected

utox is a good example of this done relatively right, where you can protect your local account (local data in this case) with a password after access but you could also go the RetroShare route and enforce a password regardless to even use nheko at all it'd just be a bit weird if forced, to be prompted for an extra password at startup, given you need another password to login to Matrix (or you could use that Matrix password to encrypt the local data with like you use the password generated by keepassxc or the keyring)

I don't mind copying the generated password from keepassxc to the input field of nheko to unlock the data by (what would normally be done by dbus)... but there needs to be a better, less bloated/insecure method than dbus.

Alternatives

I haven't found any alternative implementations of dbus (I personally don't care about integrations enough to look)

the best solution I have here is to just call execp() directly but this is generally for stuff like "Open with" in context menus or start menus of programs like file managers or window managers

wouldn't really have much use here aside from maybe right-clicking attached media or links (even then, my programs and web browser are portable, so I'd have to configure the commands/paths manually within nheko) ^ which additional convolution here uses multiple portable home directories for portable configs, nheko included.

Additional context

other issues caused by dbus are:

it breaks nemo (this is more due to nemo's poor programming, but nemo works perfectly fine without dbus, and all of it's issues it'd have otherwise (singular daemon crashing all windows, inability to access flash drives, and so on) are completely removed)
other apps automatically try to integrate with it to do more than they should have to (this stuff can't normally be disabled, and requires firejail (additional bloat) to otherwise force the software to behave)

Happens in the latest version

[X] Yes, this feature is still missing.

Duplicate of #1390

We are not going to reimplement the functionality of several other applications just because you consider dbus insecure, which it isn't (or at least it isn't less secure than anything we would implement to replace it). There is a hidden flag you can add to the settings file to not need a secrets service, but that means your database is unencrypted, which we don't support and any problems that causes for you in the future are squarely your own fault. Dbus isn't only used to encrypt the database, it is also used for notifications, restricted file access when using a portal, notification counts in the task bar, to expose an endpoint to set your status message and will be required for screensharing on some platforms. We won't make it optional, because nobody of us would run such a configuration or want to maintain it. Please look for duplicates and the reasoning there when filing an issue, especially when the dupe is just a few hours older, thank you.

reimplement the functionality of several other applications

that's not what I said

I'd be the one re-configuring the functionality of the paths in the options if you just allowed me to do as such

There is a hidden flag you can add to the settings file to not need a secrets service

sad that the user has to be forced to build this because Linux just can't be easy to use

but that means your database is unencrypted,

which is why I suggested an option to keep the database encrypted although you could just use the matrix password for this if you want ease

Dbus isn't only used to encrypt the database, it is also used for notifications, restricted file access when using a portal

which is why I should be able to configure paths for integrations and Nheko should display it's own notification windows if no bus is found (it's not like that's hard to code or anything, I'm doing that in my own apps) don't ask me to spend time learning your code structure though, you already know your structure I'm just telling you it's easy to implement

notification counts in the task bar

wait, why is that using dbus and not xorg/wayland, or whatever other higher-level API by Qt if you're already using cairo, rendering fonts to images should be stupid easy

and will be required for screensharing on some platforms

why not just use ffmpeg or mpv and have those be configurable??

We won't make it optional, because nobody of us would run such a configuration or want to maintain it.

way to be a bad dev letting your personal preferences get in the way of others who are the wiser and just want to use their PC without having to build every program they use.

I get I'm not paying for anything and all, but give me a break I can't even use it at all because you refuse to allow people the option to use dbus or a basic password if anything at all I thought the choice was supposed to be on the user and not the developers but I guess everyone's forced to become a developer just to have any sort of freedom on Linux

also, have a meme-image about dbus being insecure: (forget the source of the screenshot, probably GNU or RedHat, or something like that) https://jump.matthewevan.xyz/i2p/pxbcwxbhxj2wusliwhrb6ym4vcwpihztuf2tfjejrcdzqrmnjuoa.b32/_/ca00f5ab99e62a3a4c8ccf60e168f487c8a6a3881780addbb0d1fdfd269cf76c

additionally my issue with dbus being insecure is the TCP/IP accessability it's so secure it automatically makes all bound actions open to the network for anyone over the internet to control

sad that the user has to be forced to build this because Linux just can't be easy to use

It is a flag in the config file and it is not exposed to users by default, since it is not a functionality, that we want people to use (since it is insecure).

which is why I suggested an option to keep the database encrypted although you could just use the matrix password for this if you want ease

That would mean to maintain a reimplementation of another password prompt integrated into the client. Just because someone thinks DBus is bloat, doesn't mean I want to add "bloat" aka unused features to Nheko, especially for something as sensitive as this. And you can't use the matrix password for that, since some homeservers don't even use passwords (also it would be a terrible idea, since your homeserver knows your password in plain text and this is used to encrypt E2EE data, which your server should never be able to decrypt).

which is why I should be able to configure paths for integrations and Nheko should display it's own notification windows if no bus is found

Again, you are telling me to reimplement, what your OS offers via DBus in a worse way. This won't integrate with "Do not disturb" of your notification daemon, isn't even possible on wayland (in a reliable manner) and in general has a lot of issues, that you don't seem to be aware of.

wait, why is that using dbus and not xorg/wayland, or whatever other higher-level API by Qt

Because the task bar is drawn by your desktop environment and dbus is the official method to pass data to it.

why not just use ffmpeg or mpv and have those be configurable??

Dbus is used for permission management, so that you are allowed to access the data of other windows on wayland. If we would use ffmpeg, then ffmpeg would just need to call dbus. That doesn't really solve your problem, does it?

way to be a bad dev letting your personal preferences get in the way of others who are the wiser and just want to use their PC without having to build every program they use.

You can always write a patch, but maybe you should do some research before that. You seem to lack a lot of understanding for the complications, that writing such a patch would have. As a maintainer I am taking the time to tell you about that and that this would be a significant cost for us to support and we don't want to spend our resources on that. It isn't even completely possible to provide the same featureset without dbus.

but I guess everyone's forced to become a developer just to have any sort of freedom on Linux

Being able to code up the things you want is always beneficial to get exactly what you want. Sadly I have limited resources and I can't fulfill every wish that someone on this bugtracker has. As such I need to prioritize on the most beneficial things as well as what actually is useful to me. I develop this software mostly for myself and people that I want to do a favour. The source code is provided for anyone who finds it useful, but I am not building this, because I want everyone to use it or some other grand or noble goal, sorry.

additionally my issue with dbus being insecure is the TCP/IP accessability it's so secure it automatically makes all bound actions open to the network for anyone over the internet to control

This is wrong. You need to explicitly OPT-IN to make dbus listen on non-local TCP and it is deprecated on unix platforms since 2018.

also, have a meme-image about dbus being insecure: (forget the source of the screenshot, probably GNU or RedHat, or something like that)

Nowadays sandboxing handles dbus much better and it is used to expose only specific interfaces in sandboxes, which is more secure than giving every app full access to your whole system, because it needs to read a file or record a window.

In general, please consider that this isn't the first time I am having this discussion and please educate yourself more on the matter, before making up invalid security issues. Thank you.

of your notification daemon

I don't actually have a notification daemon I have enough apps which show me their own notifications :P (Librewolf, RetroShare, flameshot, and a few others) but yeah, showing a notification is easy enough to just create a child window with the notification text in fact you'll have even more control over it to customize things how you like

Because the task bar is drawn by your desktop environment and dbus is the official method to pass data to it.

I just use xorg and wayland for that they have methods for displaying an interactable icon in the notification area (best I have though is some example code for it, I haven't been able to play around with it yet) but I'm sure Qt likely has something

You can always write a patch,

with respect it would probably be easier if I just wrote my own matrix client in my own GUI toolkit

you're right in that I know nothing about patching I'm usually better at making feature requests and working with the devs when they want to work with me me working on a patch is just yet another project on my plate I won't be able to get to in any reasonable time I'm already overhauling the userspace and working on a software suite with a few games on top as just a few main projects the only difference is I'm working on everything offline to make sure it's ready first or you'd see my forgejo on I2P with at least 30 public projects (I refuse to use GitHub for my projects since it stopped being freedom-focused a while ago, and even GitLab noted on my profile has gone to S) (I prefer owning my code, not being owned by the repo I use) ^ if I'm working with someone, I'd prefer they own their code as the official maintainer, while I'm just the participant (being FOSS, if I was a co-dev and had qualms about something the owner wouldn't implement, that's what FOSS is for, I can just fork my own branch with my feature, since I'm an active developer of the project and not just some user being told to build it myself)

Being able to code up the things you want is always beneficial to get exactly what you want. Sadly I have limited resources and I can't fulfill every wish that someone on this bugtracker has.

the problem with this ideology (and something I personally hate) is that it's not practical go tell your friend's grandma to learn to code and see how she responds to your program breaking for her because she's using Linux for managing her photos and wants a secure communication medium that's actually decent to use I doubt she has any real programming knowledge let alone the time to learn it (I'm kinda similar in that aspect given the work I'm already doing, even if I know how to code, I don't have the time nor brain capacity to learn yet another project)

since your homeserver knows your password in plain text and this is used to encrypt E2EE data, which your server should never be able to decrypt

also btw it's not stored in plaintext and bcrypt is used to hash that password

Dbus is used for permission management, so that you are allowed to access the data of other windows on wayland

also isn't that polkit and not dbus?? (something I also don't have on my system for being an insecurity)

If we would use ffmpeg, then ffmpeg would just need to call dbus. That doesn't really solve your problem, does it?

also no, I use ffmpeg with mpv (all portable made from my artix pkg cache) it works just fine without dbus

doesn't mean I want to add "bloat" aka unused features to Nheko

also it wouldn't be unused I'm not the only one who prefers lightweight distros and it's a hinderance to have dbus be the ONLY solution you don't need dbus to encrypt a database, proven by RetroShare, utox, I2P, IPFS, and many other things which have their own solutions

much like how you don't need dbus for a majority of what you say you need it for I'm able to do it in my software, I don't see why it's so difficult for you in fact I'm providing dbus integration through plugin support in my software similar to what I'm doing for GTK integration (system themes) and more it's all for what the user wants to do, not what I want to do :) I'm giving the user their freedom to do what they want with my software not restricting them to my ideas, since that's not what the Libre/FOSS spirrit is about

modularity through plugins is awesome. :)

I don't actually have a notification daemon in fact you'll have even more control over it to customize things how you like

We don't want to customize it. We want to follow the system preferences as much es possible. Especially for something as important and frequent as notifications. Duplicating the code to render a notification in Nheko, that a system daemon could provide for all apps is the definition of "unnecessary duplication". It increases the likelihood of bugs, makes development of new features harder and Nheko heavier to run. Nothing of that is desirable to me and it doesn't align with any of the goals Nheko has.

they have methods for displaying an interactable icon in the notification area

That is not the task bar. The task bar lists your open windows/applications usually. The tray is for other stuff like background programs, etc. Not all systems have both of them.

it would probably be easier if I just wrote my own matrix client in my own GUI toolkit

I agree. Maintaining multiple implementations on how to do everything in Nheko as well as ways to switch between those at runtime is probably much more overhead to maintain, than just having multiple clients. There are actually several other clients, some of them might fit your requirements better!

I'm usually better at making feature requests and working with the devs when they want to work with me me working on a patch is just yet another project on my plate I won't be able to get to in any reasonable time I'm already overhauling the userspace and working on a software suite with a few games on top as just a few main projects

Look, I am in a similar position. I have several projects, Nheko is one of them. I don't have the time to develop and maintain something of the size of replacing dbus in Nheko. If neither you nor I have the time to develop and maintain it, then it won't happen. Because of that I closed the issue. It is simply infeasible to implement and too much effort for too little benefit, which makes me prioritize everything else over it. So from my expectation this will never happen, which is what I tried to clearly communicate by closing the issue and explaining the problem. I would obviously love to, if it would magically be possible without spending time on it and without it causing other issues. Since that isn't the case, the issue got closed as "wontfix" because it won't be fixed by anyone.

go tell your friend's grandma to learn to code and see how she responds to your program breaking for her because she's using Linux for managing her photos and wants a secure communication medium that's actually decent to use

I clearly communicated that I am developing Nheko for myself and the people I care about. Neither your nor my grandma cares about using dbus. Making it optional on the other hand would possible break stuff she actually cares about. On the other hand I am under no obligation to implement features that actively make Nheko worse for existing users (and myself), just to implement something someone requests based on mostly provably false assumptions. There is a big difference there. I am trying to make a good program, that I and people I care about enjoy to use. If you are not in that group, you either need to contribute yourself, find someone to contribute for you, become part of the people I care about (by for example having done something I appreciated) or demonstrate, without a lot of back and forth, but by doing proper research upfront and actually thinking about all aspects more than a minute, a good way to implement, the edge cases and possible solutions for a feature. Currently most of your arguments decidedly lack an understanding for the problem at hand and any issues I raise are responded by other incomplete and ignorant "solutions", that don't solve anything. Good issues are always appreciated and eventually considered. However replacing something as foundational to Nheko as DBus needs an equally foundational research of the full problem space. And you actually need a good reason for why you want the feature. In this case the only reason are your opinions on DBus, funded on provably false assumption (like DBus defaulting to WAN accessible TCP). As such there is no reason to consider implementing your feature request.

also btw it's not stored in plaintext and bcrypt is used to hash that password

This is not really relevant, considering the raw password is sent over a tls encrypted https connection (usually) every time you login. This means your server can gain knowledge of your password at any time, cloudflare and other similar services know your password and in general your password can't be considered secure and secret from your server. Yes, matrix servers usually hash the password, but that is after receiving the password in plain text and everytime they receive it in plain text. For End-to-End-Encryption this can not be considered secure. For that Matrix would need to support something like OPAQUE (from cloudflare) or similar.

Once again I ask you to please research and consider your argument more before asking me to reply to it. You seem to lack understanding of the tradeoffs at hand and you don't act like you are aware of this. This means it takes me a lot of time to point out the fault in your argumentation, that I could better spend on productive things or eating cake with my grandma. Please value my time as a fellow human being, thank you.

also isn't that polkit and not dbus??

Currently the only cross platform API to request to grab a video stream from other applications on Wayland is the freedesktop screencast protocol: https://docs.flatpak.org/en/latest/portal-api-reference.html#gdbus-org.freedesktop.portal.ScreenCast

Most applications even outside of flatpak use it, because otherwise there are no stable APIs to use. Otherwise there is no reliable way to grab other applications and stream them on Wayland and if there is one, that is usually because your application has higher privileges than it should have or because your Wayland compositor is not very secure. After all Wayland is supposed to prevent Applications from reading other applications screenbuffers without the user knowing and allowing that.

Considering that your main argument against dbus is security, I would hope you are aware of those tradeoffs and did your research instead of asking me to spend time on explaining to you, why that is wrong. It is not hard to research the issues with screenshare on wayland by googling or looking through this issue tracker and I would expect our discussion to include equal research on either side or even possibly more on your side, considering it is you asking me to implement something. Thank you.

also no, I use ffmpeg with mpv (all portable made from my artix pkg cache) it works just fine without dbus

I couldn't find anything on capturing wayland windows with ffmpeg (and it is worse for mpv). I think you are confusing video playback with capturing application windows? In any case if ffmpeg supported it, it would presumable use pipewire. The screencast dbus API is one way to obtain pipewire streams for applications. You can probably manually pass pipewire paths or similar, depending on your wayland compositor, but I don't see how to implement that in Nheko in a user friendly manner, without requiring access to the pipewire socket and even then, I might be missing some compositor specific bits. In any case, I don't think ffmpeg supports that right now, so I think this argument is invalid, but maybe you have some documentation, that I couldn't find for it?

also it wouldn't be unused I'm not the only one who prefers lightweight distros and it's a hinderance to have dbus be the ONLY solution you don't need dbus to encrypt a database, proven by RetroShare, utox, I2P, IPFS, and many other things which have their own solutions

Implementing a big feature for a single user is the opposite of lightweight. I doubt users of lightweight distros would prefer a Nheko, that has lots of features for very specific and niche users. Using dbus Nheko can be more lightweight by having some tasks rely on common APIs. If 2 applications do that, you saved resources. Dbus is not only used to encrypt the database, but requesting a secret to encrypt the database with is one of the tasks and I would prefer to keep it at that, instead of reimplementing half a password manager in Nheko. Adding any second way to do this, will be a hindrance to adding new features as well as keeping existing ones stable.

I'm able to do it in my software, I don't see why it's so difficult for you

I literally listed pages of difficulties...

I'm giving the user their freedom to do what they want with my software not restricting them to my ideas, since that's not what the Libre/FOSS spirrit is about

Any user can do anything they want with Nheko (apart from what the GPL disallows), but no user can force me to do anything or restrict me from spending my time on more useful things. FOSS is about collaboration, not about making others do stuff for you. And it is common and even beneficial in FOSS to just fork and implement what you like there and then have upstream pull it, when they think it is useful. I think you are seriously misunderstanding something here.

modularity through plugins is awesome. :)

Sure, but it has a cost. And you need an API to talk to plugins. In our case that API is implemented using dbus, which allows you to replace several components with the ones you want. Like your secret storage, your notification daemon, your compositor (for screenshare stuff), integrate Nheko into your music player, pick any task bar you like and more. You are not asking for modularity though. You want us to make our existing system for modularity replaceable at runtime with another system. You are basically asking for meta-modularity and that is too complex for Nheko to support without serious downsides.

If neither you nor I have the time to develop and maintain it, then it won't happen.

*sigh* yeah, that's fair at least that's a more reasonable answer than "build it yourself" or other flack like I commonly get and I can respect that

which is what I tried to clearly communicate by closing the issue and explaining the problem.

I have years of scars from the Linux community's abuse and am deathly sick of being told to just do everything myself, where it seems like the dev just doesn't want to do anything to actually improve their app

at least this was a much more respectful issue, and I love it when things go this way even if neither of us can reach a conclusion, I'd rather it end with respect than enemies being made out of it thank you for not being a soydev :)

Making it optional on the other hand would possible break stuff she actually cares about.

this I disagree with I'm used to commonly having to RE everything because something like pulseaudio, XFCE, rofi, or whatever F's up somewhere and the source is just so spaghettified and unmaintainable that's it's better to just rewrite the thing in 10 lines under my own implementation, than work with the 5000 lines of nonsense that could be done far better

for an actual thing I'm doing currently that would be replacing GLFW with the X pipe (xorg)

but anyways, to get to my point on that you can do a much better job if you just do it yourself and not rely on dependencies but that includes also having the knowledge to do so

like I get the need for having an encrypted database, and in fact would rather prefer not to lose that, while also removing dbus where as with notifications on the other hand, I've sadly had to lose those

if I could make a suggestion here try to make slow progress towards making dbus integration into a plugin (I don't expect anything soon out of this) this can be done securely if you're careful with how you design your plugin API

but yeah, all I can say is to try to work towards it, so you can support both people who don't mind dbus and people who want to run on less than 100MiB of RAM use for whatever reasons they have (I'm in a group with someone who's trying to get an 8MiB kernel working for themselves on this note)

Nheko is amazingly lightweight as is but a plugin system with aspects you can disable would help make it even lighter and more customizable heck maybe even more secure if you remove web-specific integrations and such

but anyways, yeah, my core point is to just make small changes to make nheko even better for this stuff :) thank you for providing an appimage again as is I just hope one day I'll be able to actually use it since no other client does everything nheko does

And you actually need a good reason for why you want the feature. In this case the only reason are your opinions on DBus

my reason is I don't trust the security of it and in addition, just don't need it (nor really want it even)

but for some actual meat to that reason it breaks quite a few programs I use where I'd have to use firejail, reinstalling a bunch of stuff I've also removed (python for example) just to make these programs behave again

or even then, nemo would never behave again if I reinstalled dbus like for example, I wouldn't be able to access my flash drives anymore after mounting them without restarting nemo (I'm using an old version that displays all my drives properly, so an update would break even more functionality just to fix that issue above)

so I'm just better off without dbus there as a whole since nemo actually functions properly currently it detects my flash drive and opens it in a new tab just fine after mounting it without dbus (nemo is my biggest issue here, which no other file manager compares to)

but there are other things that would break as well if I reinstalled dbus like my web browser would crash a lot more often trying to send messages through it and getting no response from the target apps I don't have (I don't have GTK or Qt on my system for example, and am even getting close to removing fontconfig)

I'd ultimately like to remove glib2 for being nothing but problematic with a lot of my portable apps like Xed for example has become completely broken because it tries to use my system's glib2 for stuff, and breaks because that stuff only exists locally in it's AppDir

so removing stuff like that would help give me a much more stable system and that stability is my ultimate goal as probably my main hidden reason for removing dbus

I hope that at least helps you actually consider supporting my type of setup :)

I would hope you are aware of those tradeoffs

also yes, I'm aware of what I lose however, it's not the be-all end-all of things just reimplentation would be much more direct with possibly more to configure (if you don't use sysfs or kernel calls and such to figure this stuff out)

to boost my security, I'm trying to get rid of as much network integration as I can, because if TCP/IP were secure, $ traceroute would never return any accurate info, no would you be able to see the physical IP of your target only a relative identifier with no protocols that give any information about the target device (a fight back against shadow-profiling)

but anyways, I'm just loosely mentioning that the more I can get away from things that integrate with the network, the more secure I'll be

I just need the apps to integrate with their respective servers I don't need anything the apps use to also integrate with the network (I wish I had a HIPS on this note so I could be notified about an attempted action that I'd have to allow or deny while that action remains on hold for my input)

but anyways, yeah, I'm fine with what I lose I don't like anything going over the network other than what's intended (like with nheko, I only intend to connect to matrix servers, and not have dbus tell google anything) ^ if that may be configured by my distro

I only want control over what I want connecting with what, and nothing more.

it would presumable use pipewire

why not ALSA instead, which should be capable of supporting it (I only use ALSA on my setup as well, because all audio servers have been problematic for me) ^ at least pipewire recovers it's dropped streams, but still, ALSA never drops anything to begin with.

so yeah, yet another avenue to look into :P

I aim to go more minimal than WinXP, without going full on CLI while also being able to have manually configured integrations with screenshare and such and for screensharing, yeah I was confusing the recieving end of the share, not the broadcasting end, which might require something like v4l integrations

I think you might be starring to notice the theme with me now manual configurations are more stable/secure than automated configurations because with automated configurations, you never know who actually has access to your system and there's no HIPS to tell you and hault when someone tried to connect to you under your nose like I had with Comodo on WinXP: (they suck now, I'm not advertising them) https://jump.matthewevan.xyz/i2p/pxbcwxbhxj2wusliwhrb6ym4vcwpihztuf2tfjejrcdzqrmnjuoa.b32/_/bc159cc446b112de223c161457faddf6bb63e4e270be450861b300dbe88d3dc0 (yet another PNG, I've been betrayed enough by image hosts that want to own me)

I doubt users of lightweight distros would prefer a Nheko, that has lots of features for very specific and niche users.

I'm not getting at the many niche features aspects as that I understand potentially being heavy they should be done within reason

Using dbus Nheko can be more lightweight by having some tasks rely on common APIs.

actually, I'd argue that makes it more heavy as you additionally need dbus-daemon and other APIs sitting in RAM that nheko depends on rather than nheko using as little resource as possible to achieve the same goals

but yeah, like I said, please take your time with this if the task is very complex :)

but no user can force me to do anything or restrict me from spending my time on more useful things.

also btw, I'm not trying to

get to it when you can just please try to actually get to it WHERE you can :)

yes, we're all human just we as developers (speaking as me for my own projects and you for yours) have opted into providing for the users we may not be obligated to actually do what we've opted into doing but if we don't want to be S soydevs, we should at least try to make the user experience better for people where needed even in the niches without being too unreasonable (building your own password dialog I don't consider to be too unreasonable) ^ it's just a matter of finding the space to be able to work on it

thus what I'm getting at is find a way to do everything without making your structure bloated and spaghettified

for example I have a GUI toolkit that even does 3D models and gradient/UV-mapped fonts (more than web) but the actual code for it is less than 300K in size (all modules) currently (doesn't include bindings, only the toolkit) (security is currently questionable, and will be strengthened in time, most likely increasing the code size)

anyways, I feel like I'm getting a little to far off into offensive territory, so I'll cut it short here as that's not my intent I just want to give insight at that, and hope you consider in favor of it (it may not be as convoluted as you may think, though may require a bit of tediousness to prepare for it)

basically... come back and revisit this later :)

In our case that API is implemented using dbus

why not just bind a blob and call functions instead seems much simpler that way than requiring a sophisticated daemon to shove messages through :/

I can agree to disagree on all of this but like please, all I ask is you sit on it and make small efforts towards it

it's better to just rewrite the thing in 10 lines under my own implementation, than work with the 5000 lines of nonsense that could be done far better

This begs the question: why can't you just write a minimal D-Bus implementation that will do the bare essentials without any of the things you don't like about current D-Bus implementations?

I respect your wish to have a lightweight OS with no bloat, but I really think that it's hardly our place to be trying to appeal to everybody. As I mentioned in another issue, we technically are under no obligation whatsoever to implement any feature. If we wished to create a bloated monster app out of what we currently have or if we wished to intentionally introduce insecure behavior, we could do so and nobody could force us to do it differently. The current aim of nheko is to have a client that is nice to use for most people, even if they are not technically inclined, and as such I think that catering to niche usecases like yours is going against the goals of the app.

To be clear, I don't want to come across in the wrong way here. I respect that you are interested in giving feedback to help improve nheko, and I think I speak for the maintainers as well as myself when I say that that is greatly appreciated. However, there are some things that just never happen, and this likely is one of them.

Thank you for being understanding with this situation. :)

(And also, I have added a useful D-Bus API to nheko that allows for cool plugins like my nheko-krunner project, and I don't think we really are interested in breaking those projects)

If we wished to create a bloated monster app out of what we currently have

now hold on there :) what I've said all along is this could be relatively easily done aside from making dbus a plugin-based integration the actual notification window is basically nothing to write

and a password input dialog is roughly nothing to write as well though I recommend looking into RetroShare for a potentially secure way of doing it (since I know you don't just want to pass the password as a function argument)

in fact all I really need is just a way to input my password from keepassxc into some method of input to decrypt the database by (I would prefer to use my existing encrypted database I already have, meaning very little should need to be changed) ^ the existing mechanics should be able to make use of the result of the password dialog as if it were the result returned from keepassxc

the only security concern would be the dialog itself, since everyone hates pkexec for the same reason

(And also, I have added a useful D-Bus API to nheko that allows for cool plugins like my nheko-krunner project, and I don't think we really are interested in breaking those projects)

and yeah I don't want you guys to break anything just adapt it to more direct implementations to avoid issues like a system with no dbus

I get that you want to make nheko easy to use for the people who don't care about dbus being a potential insecurity or whatever, and the rest of this stuff and I absolutely do not want to take any of that away :)

in fact I advocate for apps being easy to use, Linux needs more apps like this... but I also advocate for depending on practically nothing at all while achieving that that doesn't inherently mean you need to write mountains of code just to achieve that that's why I gave my example of my UI toolkit being less than 300KB in size it's tiny, but it does more than GTK

basically... if I can achieve that, you should be able to as well :)

but I'm not demanding anything, yes you're ultimately obligated to do whatever you want I only hope you'd consider it for a wider audience of those who actually don't want anything to do with a dbus implementation while still giving them the ability to use what's literally the best Matrix client

also btw I wouldn't know where to start with writing my own dbus client sure it might be minimal but unless it's something I could just run with nheko just to get it working I don't really want to go the extent of binding it to OpenRC and making it a part of my system since that defeats the purpose of what I'm trying to achieve

plus I don't think it would work well with Nemo and all my other apps that would break with it anyways... >_> so yeah, doubling down on having it be something that starts with nheko as part of the AppDir...

now hold on there :)

Sorry, I meant this in the context of "if we wished to add all sorts of unnecessary things like an integrated web browser and in-app games for easter eggs or something and...", not as "implementing this will massively bloat nheko". I probably should have been more clear there.

like an integrated web browser and in-app games for easter eggs or something

oh that what I was saying there (above) was to go to your options and specify the path for your web browser to launch when you click a link then nheko could just pkexec() that :) (I'd personally leave it blank myself)

please for the love of god do not code your own web browser XD games maybe, but even then, it's still excessive... lol

dangit I meant to say execp() not pkexec() x.x

I can't edit that >.<

Nheko-Reborn / nheko