4 ms·

their reply in that issue: "We don’t plan to implement this directly, as it is designed for test initially, we do not recommend using RustDesk with a public IP

by trueno 2mo ago

their reply in that issue: "We don’t plan to implement this directly, as it is designed for test initially, we do not recommend using RustDesk with a public IP alone, that's also why direct ip access is turned off by default. For security and privacy, we strongly advise using it in combination with a VPN—the VPN tunnel already provides end-to-end encryption, so additional encryption within RustDesk is unnecessary in that setup. That said, we welcome community contributions! Many users express interest or share feedback—but very few take the next step and submit a pull request. If you’re able to help, your PR would be greatly appreciated! "

LoganDark 2mo ago
> That said, we welcome community contributions! Many users express interest or share feedback—but very few take the next step and submit a pull request. If you’re able to help, your PR would be greatly appreciated! hate this. "we don't want this on principle... but we would accept it if you did it yourself!" just say you don't feel like it! don't act like it's a bad thing except for when somebody else does it for you, that's just dishonest.
- trueno 2mo ago
  yeah it's definitely confusing messaging i can't imagine being a community contributor there and saying "ok im gonna help implement this thing that they just described as not a good fit for their thing". i think being under resourced or whatever or just not having anyone on the team that would be able to pull this off is a fine thing to be forward about, but it gets confusing because they kinda frame it like it's the wrong thing to do then leave the door open for someone else to do it. if they didn't beat around the bush perhaps they'd have encryption on this already.
  - LoganDark 2mo ago
    I prefer when projects say "we don't have the resources for this but we agree it would be nice" because then I actually feel like it would be worth the PR. but this project makes me feel like they don't want the change which means I don't want to put in the work
    - deleted 2mo ago
      [deleted]
- embedding-shape 2mo ago
  > hate this. "we don't want this on principle... but we would accept it if you did it yourself!" just say you don't feel like it! don't act like it's a bad thing except for when somebody else does it for you, that's just dishonest. What is there to hate here, I don't understand? They first provide a concise overview of the current situation. Then how they personally feel about it. Finally they leave it open and end it with "If you want it badly enough, we'll accept outside contributions for it". They're not saying that they're against the feature in principle, they're saying that they themselves don't plan to spend time implementing it, but if users really want it and contribute the feature itself, they'll be happy to maintain it once merged. This seems like the ideal solution? What would be better here?
  - LoganDark 2mo ago
    First they say they do not want the feature: "we do not recommend using RustDesk with a public IP alone, that's also why direct ip access is turned off by default." Then they say you should contribute it. It's mixed messaging, it seems like they're trying to hide "won't implement this" behind "this is a bad idea in general". They should just say they won't implement it and that they're open to contributions, not that it's a bad idea and that they "strongly" recommend against it, but that maybe if someone opens a PR anyway they'll consider it.
    - embedding-shape 2mo ago
      > First they say they do not want the feature: "we do not recommend using RustDesk with a public IP alone, that's also why direct ip access is turned off by default." Massive misunderstanding from your perspective if this is your take away. They're saying that based on the current state of the program, they don't recommend that particular approach. Nowhere in that quote of yours, does it give an indication that they don't want that feature. The only thing unambiguous from that quote, is that due to the current state of the program, they don't recommend that approach, and explains why one of the defaults is like it is. If they didn't like the idea, or didn't want the feature, they'd say so, but they do not say that out loud, so why would you assume so?

by trueno 2mo ago

LoganDark 2mo ago

> That said, we welcome community contributions! Many users express interest or share feedback—but very few take the next step and submit a pull request. If you’re able to help, your PR would be greatly appreciated! hate this. "we don't want this on principle... but we would accept it if you did it yourself!" just say you don't feel like it! don't act like it's a bad thing except for when somebody else does it for you, that's just dishonest.

trueno 2mo ago
yeah it's definitely confusing messaging i can't imagine being a community contributor there and saying "ok im gonna help implement this thing that they just described as not a good fit for their thing". i think being under resourced or whatever or just not having anyone on the team that would be able to pull this off is a fine thing to be forward about, but it gets confusing because they kinda frame it like it's the wrong thing to do then leave the door open for someone else to do it. if they didn't beat around the bush perhaps they'd have encryption on this already.
- LoganDark 2mo ago
  I prefer when projects say "we don't have the resources for this but we agree it would be nice" because then I actually feel like it would be worth the PR. but this project makes me feel like they don't want the change which means I don't want to put in the work
  - deleted 2mo ago
    [deleted]
embedding-shape 2mo ago
> hate this. "we don't want this on principle... but we would accept it if you did it yourself!" just say you don't feel like it! don't act like it's a bad thing except for when somebody else does it for you, that's just dishonest. What is there to hate here, I don't understand? They first provide a concise overview of the current situation. Then how they personally feel about it. Finally they leave it open and end it with "If you want it badly enough, we'll accept outside contributions for it". They're not saying that they're against the feature in principle, they're saying that they themselves don't plan to spend time implementing it, but if users really want it and contribute the feature itself, they'll be happy to maintain it once merged. This seems like the ideal solution? What would be better here?
- LoganDark 2mo ago
  First they say they do not want the feature: "we do not recommend using RustDesk with a public IP alone, that's also why direct ip access is turned off by default." Then they say you should contribute it. It's mixed messaging, it seems like they're trying to hide "won't implement this" behind "this is a bad idea in general". They should just say they won't implement it and that they're open to contributions, not that it's a bad idea and that they "strongly" recommend against it, but that maybe if someone opens a PR anyway they'll consider it.
  - embedding-shape 2mo ago
    > First they say they do not want the feature: "we do not recommend using RustDesk with a public IP alone, that's also why direct ip access is turned off by default." Massive misunderstanding from your perspective if this is your take away. They're saying that based on the current state of the program, they don't recommend that particular approach. Nowhere in that quote of yours, does it give an indication that they don't want that feature. The only thing unambiguous from that quote, is that due to the current state of the program, they don't recommend that approach, and explains why one of the defaults is like it is. If they didn't like the idea, or didn't want the feature, they'd say so, but they do not say that out loud, so why would you assume so?