[Feature Request]: Change the name from 'Remotely Secure' to another one

[MartinJDavis93]

What feature are you suggesting?

The name 'Remotely Secure' doesn't sound good. I've been using 'Remotely Save' since 2021 when it was introduced, and I've never had any issues with it. Everything worked perfectly. This week, I decided to open a couple of issues to improve it. Personally, I've been missing these fixes for a long time, but I somehow didn't dare to publish them. Upon visiting the page, I saw that the extension is practically not being developed, and it's very sad. Even though I'm practically satisfied with 'Remotely Save,' I decided to check if there are other options that have emerged over the years. Though, I repeat, 'Remotely Save' suits me in almost everything. And looking through the list of extensions, every time I bypassed 'Remotely Secure,' not even reading its description, assuming it's related to encryption or something like that. I didn't really like the name 'Remotely Save' at the beginning, and I wrote that maybe it could be renamed somehow to have a name associated with synchronization, but back then, the author and I agreed that it was okay as it is. And over the years, I've gotten used to it. But 'Save' in the name can somehow be associated with synchronization and saving, unlike 'Secure.' I understand that the idea is to fork 'Remotely Save' to fix security issues (hence, 'Secure') and keep it afloat. But you've already mentioned all of this in the description. There's no need to deviate from this in the name of the extension. Therefore, I would recommend changing it. There are many different options, such as 'Sync' (the easiest and logical option, analogous to the paid Obsidian Sync), 'Synchronize,' 'Remotely Sync,' etc., especially since I see you're planning to refactor. This will make it much easier for users searching for a free synchronization option in the midst of various plugins.

What remote cloud services are you using, or suggesting adding the feature to?

No response

Ensure no sensitive information

• [X] I ensure that no sensitive information is submitted in the issue.

[sboesen]

Thanks for opening this issue! I definitely agree the name can be improved. I'll have to look into the process of changing it, and think about your suggested names.

"Remotely Secure" was also meant to be a play on words, that is was at least "remotely" secure (no guarantees) but this is also called out in the readme. Agreed that a name change would probably improve discoverability (though searching plugins does search the description, which we can change).

[MartinJDavis93]

Thanks for opening this issue! I definitely agree the name can be improved. I'll have to look into the process of changing it, and think about your suggested names.

"Remotely Secure" was also meant to be a play on words, that is was at least "remotely" secure (no guarantees) but this is also called out in the readme. Agreed that a name change would probably improve discoverability (though searching plugins does search the description, which we can change).

For me, the word 'Remotely' is just a transfer word from 'Remotely Save', and the role is played by the second word. If you search for plugins with the query 'Remotely', it gives the impression that 'Remotely Secure' is just another plugin from the same developer as 'Remotely Save', just with a different purpose, something related to security. Until you start reading the description and look at who the developer is. In any case, you would agree that it's very strange that a plugin directly related to syncing notes/files, which is its main task, doesn't use any variation of the word 'Sync' or even 'Save' in its name, which could somehow be associated with the plugin's purpose. Instead, it associates itself with 'Secure', even though the variations of the word 'Sync' are not used by any other plugins, at least for now. Variants like 'Sync' or 'Synchronization' sound simple and easy to remember. And you won't confuse them when telling someone that for synchronization, you can use 'Remotely Secure', and he can't remember whether it's 'Remotely Secure' or 'Remotely Save' and installs the one with more votes. I'm not suggesting changing the description and not to mention that this is a fork of 'Remotely Save'. Yes, it is a fork of 'Remotely Save'. But that doesn't mean you have to stick to a similar name. The name should be simple, easy to remember, and convey the essence of the plugin's purpose immediately.

Overall, I don't know the whole history. I assume you've already tried to contact the developer of 'Remotely Save' (formerly fyears, and the repository was directly linked to him, now I see it's a separate repository called remotely-save). It would be great not to create forks but to contribute all your changes to 'Remotely Save', so that everyone benefits. Your improvements don't contradict the idea of 'Remotely Save'; they are simply enhancements. You could just join the 'Remotely Save' team, gaining access to the repository, and together you could support it, without creating fork. A larger team has more chances for further improvements.

[sboesen]

Definitely hear you on the name and will take some time to consider how to go about changing it. It's not super high priority on my list but happy to change it.

The security issues combined with the fact that it's not maintained inspired me to make the fork, my goal is to help others that want to use a more secure sync plugin but certainly not worrying about market share etc. Primarily made these changes for myself & to get the plug-in working on mobile!

More than happy to send the changes upstream as a PR but it hasn't been a priority as Remotely Save isn't maintained and we have some (long lasting) bugs to squash with my limited free time.

[sboesen]

Created an issue offering to open a PR. I don't expect a response but offer extended :D

[MartinJDavis93]

Created an issue offering to open a PR. I don't expect a response but offer extended :D

Oh, that's great, good to hear.

[MikeWi11s0n]

+1

[kadisonm]

On a side note but slightly related. If your PR doesn't get a response.

@sboesen sboesen

Created https://github.com/remotely-save/remotely-save/issues/396 offering to open a PR. I don't expect a response but offer extended :D

Would you ever consider making this repository stand alone (alongside name change)? Especially since you're putting so much work into it. At some point the plugins will basically be two different ones, and your visions and structure for it different.

Maybe not right now, but I'm curious if you would in the future since you've done quite a lot of work for this.

[sboesen]

Not opposed to making it standalone in addition, and I do think we'll get to the point where features diverge enough - definitely a lot thanks to the issue filers for ideas/details on how things are currently working. Not convinced we really get any benefit from a standalone repo vs. a fork, though.

I also want to definitely give credit to the people in the credit section as they contributed more in terms of features than I have. My main contribution was improving how encryption is performed, but that was a relatively small change :)

[kadisonm]

I also want to definitely give credit to the people in the credit section as they contributed more in terms of features than I have.

Everyone's done super well on the features so far. It's a huge improvement from remotely save. :)

[MartinJDavis93]

I believe that the creators of 'Remotely Save' simply don't have the time to support it, or it's not highly needed by them. Therefore, in essence, I think they wouldn't object if 'Remotely Secure' actually absorbs 'Remotely Save', as it is not a significant source of revenue for them. In the end, the end user will only benefit from this because the 'Remotely Save' user base is significantly larger, and all your fixes will undoubtedly be appreciated by them.

Submitting a request is a logical step. If you don't receive any responses over an extended period or if your proposal is rejected, you will know exactly what to do next.

If you decide to change name, it's best to do it either at the initial stage or after you've made what you consider to be the main security fixes and key implementations. This way, the difference in functionality will be more noticeable, which will make your plugin more attractive to the end user.

[sboesen]

It looks like this issue has become more urgent - dropbox needs us to submit an official production app soon because 50 users linked Remotely Secure to their account. Once we register the app name is final, if there is a mismatch with a name change that is probably OK but not an ideal user experience.

I think they wouldn't object if 'Remotely Secure' actually absorbs 'Remotely Save', as it is not a significant source of revenue for them.

I don't think they earn any revenue at all, nor do I plan to (but that comes with no support guarantees, either, of course).

Personally I don't have any incentive to absorb the entirety of the Remotely Save user base, it's not in my interest really. I'm not chasing a user count, github stars, etc. It also means more issues to address/cleanup/dedupe, which is effort - and I would probably be largely alone in addressing these as the ratio of issues : pull requests is about 20 : 1.

That being said I'm more than happy to help Remotely Save integrate the security changes and address issues as I have time for users that want to migrate to Remotely Secure! I just have limited time and that puts a cap on how much I can put into a project.

Agreed on changing the name sooner than later! Will give it some serious thought as the dropbox issue is pushing this issue to the top of my list.

[sboesen]

I like "Remotely Sync" the most out of these options. It looks like other plugins have "Sync" in the name, so should be able to request that name change.

[MartinJDavis93]

I think they wouldn't object if 'Remotely Secure' actually absorbs 'Remotely Save', as it is not a significant source of revenue for them.

I don't think they earn any revenue at all, nor do I plan to (but that comes with no support guarantees, either, of course).

Personally I don't have any incentive to absorb the entirety of the Remotely Save user base, it's not in my interest really. I'm not chasing a user count, github stars, etc. It also means more issues to address/cleanup/dedupe, which is effort - and I would probably be largely alone in addressing these as the ratio of issues : pull requests is about 20 : 1.

That being said I'm more than happy to help Remotely Save integrate the security changes and address issues as I have time for users that want to migrate to Remotely Secure! I just have limited time and that puts a cap on how much I can put into a project.

Agreed on changing the name sooner than later! Will give it some serious thought as the dropbox issue is pushing this issue to the top of my list.

It seemed to me that they used to have donation details on their page. Now I see that they are not there. Maybe it wasn't them. At the beginning, I was considering various options for synchronization, so perhaps I confused them with someone else. I don't rule out that possibility. But let's leave that aside.

As for absorption, I'm looking at it not from the developer's perspective but from the consumer of the product, and that's somewhat different. What's the purpose of both plugins? Right, ensuring synchronization. What're the differences between 'Remotely Secure' and 'Remotely Save' at first glance for the average end-user? Not much, practically. A few additional settings, somewhat different notification options where there were '8', and now there are '2'. Essentially, that's it. The appearance itself hasn't changed. Under the hood, there are some security fixes, but they aren't noticeable because they aren't explicit changes that you can see. The number of synchronization services is the same, and even if it grows over time, it'll only be a plus. What is better for the user in the end? Two practically identical plugins 'A' and 'B', working practically the same, but in one of them (option 'B'), there are a few additional pleasant switches and settings. Probably option 'B', as long as it doesn't come with additional issues besides extra features.

I understand that if 'Remotely Save' was developing now, then a fork of 'Remotely Secure' would be created only in the event that the authors' development vector didn't match. And since 'Remotely Save' hasn't been updated for a long time, creating 'Remotely Secure' is essentially just a way to continue developing the same 'Remotely Save', but with a different developer and under a different name. 'Remotely Save' has other forks, from which you probably took fixes. So, in my opinion, everyone involved in developing forks, including the original authors of 'Remotely Save', would be better off uniting in one repository and collectively working on fixes and the development of the plugin as their free time allows. It's just more productive in the end, even if participants only occasionally contribute fixes. I doubt that the global development differences among all authors are significant. I think all implementations are based either on personal needs or community requests. Therefore, everyone can develop the direction they consider necessary and merge it all into one product. The end user only benefits from all this because they no longer have to choose between all these forks, where one has some cool parameter but lacks the useful parameter found in another fork.

Of course, uniting is always a complex problem. But it was worth a try. If it worked, everyone would benefit from it.

[MikeWi11s0n]

Very much echoes Remotely Save, precisely because of the presence of Remotely, and it's not very cool. And on Remotely's request, both plugins will be displayed, which will make it difficult to choose between them. As an option, I'll offer: Cloud Sync, OSync, ObSync, Sync to Save, Sync and Save.

[kadisonm]

would be better off uniting in one repository and collectively working on fixes and the development of the plugin as their free time allows.

Agreed. If the owner wants to merge then that's great. But if this doesn't happen after a lot of time and development the plugin should probably become standalone. Especially in the event that there is a new sync algorithm or restructure, I think there's a lot of developers that deserve recognition especially @sboesen for managing this.

Very much echoes Remotely Save, precisely because of the presence of Remotely

I agree but I think the only problem with that is the description needs to state that it's a fork of remotely save. Obsidian shows plugin results based on keywords in the plugin name and description, so it would still show up. It would definitely help differenciate them though.

[sboesen]

Very much echoes Remotely Save, precisely because of the presence of Remotely, and it's not very cool. And on Remotely's request, both plugins will be displayed, which will make it difficult to choose between them.

I think sharing the word Remotely could help relate the plugins, it is a fork after all. People can decide if they prefer a fork with lower download count and recent updates or one with no recent updates and lots of downloads. Besides, the word "Remotely" is a useful word to describe what the plugin does, so I'm not really worried here.

What're the differences between 'Remotely Secure' and 'Remotely Save' at first glance for the average end-user?

I agree we can definitely do a better job at calling out features differences between the two, definitely open to pull requests fleshing out the readme!

Of course, uniting is always a complex problem. But it was worth a try. If it worked, everyone would benefit from it.

Definitely agreed! If they begin updating Remotely Save I don't have any issue with them pulling changes they want (at this point they probably wouldn't want them all, there's a good chunk of features added and we will only diverge more). I think I explained in another post but the main benefit for me is being able to run this plugin on mobile with proper encryption; happy to fix bugs and add features as people here suggest but the goal of absorbing Remotely Save's user base is not one I share.

Minimizing support burden is definitely one of my goals, so staying small has its perks to me :) that being said if others contribute code changes I'm all for growing

[MartinJDavis93]

would be better off uniting in one repository and collectively working on fixes and the development of the plugin as their free time allows.

Agreed. If the owner wants to merge then that's great. But if this doesn't happen after a lot of time and development the plugin should probably become standalone. Especially in the event that there is a new sync algorithm or restructure, I think there's a lot of developers that deserve recognition especially @sboesen for managing this.

When I submitted this proposal, there was no time limit for merging with 'Remotely Save' or adopting a new name, and submitting 'Remotely Secure' as a stand-alone. How the duties would be divided in this case is not my business. I think the developers would be able to solve it among themselves. But this is not really important, as I understand that no feedback has been received from the developers of 'Remotely Save' during this time. Therefore, now essentially everything boils down to the choice of a further name under which the plugin will continue to exist as an independent one.

[MartinJDavis93]

Very much echoes Remotely Save, precisely because of the presence of Remotely, and it's not very cool. And on Remotely's request, both plugins will be displayed, which will make it difficult to choose between them. As an option, I'll offer: Cloud Sync, OSync, ObSync, Sync to Save, Sync and Save.

The name 'OSync' isn't quite fitting, as the abbreviation OS could be interpreted as an operating system, so it might not be entirely clear and could be confusing (as far as I understand, O refers to Obsidian). 'Sync to Save', 'Sync and Save' are short words, but ultimately it still results in a name that is too long and cumbersome. 'Cloud Sync' is not bad. However, I like 'ObSync'. It's a pretty name.

[MartinJDavis93]

Very much echoes Remotely Save, precisely because of the presence of Remotely, and it's not very cool. And on Remotely's request, both plugins will be displayed, which will make it difficult to choose between them.

I think sharing the word Remotely could help relate the plugins, it is a fork after all. People can decide if they prefer a fork with lower download count and recent updates or one with no recent updates and lots of downloads. Besides, the word "Remotely" is a useful word to describe what the plugin does, so I'm not really worried here.

What're the differences between 'Remotely Secure' and 'Remotely Save' at first glance for the average end-user?

I agree we can definitely do a better job at calling out features differences between the two, definitely open to pull requests fleshing out the readme!

Of course, uniting is always a complex problem. But it was worth a try. If it worked, everyone would benefit from it.

Definitely agreed! If they begin updating Remotely Save I don't have any issue with them pulling changes they want (at this point they probably wouldn't want them all, there's a good chunk of features added and we will only diverge more). I think I explained in another post but the main benefit for me is being able to run this plugin on mobile with proper encryption; happy to fix bugs and add features as people here suggest but the goal of absorbing Remotely Save's user base is not one I share.

Minimizing support burden is definitely one of my goals, so staying small has its perks to me :) that being said if others contribute code changes I'm all for growing

My main message was not that 'Remotely Secure' has not many visible changes for the user compared to 'Remotely Save,' but rather that people generally don't want to delve into details and search for differences between them. That's all.

As for transitioning the user base from 'Remotely Save' to 'Remotely Secure,' you can set whatever goal you want, but it'll most likely happen gradually whether you want it or not. Of course, not everyone will switch, but a certain number will migrate for sure. Therefore, you'll still receive a significant number of new issues over time. It's just unavoidable. Also, we cannot rule out the possibility that you'll cease to support the plugin a year or two from now. It's possible that another fork may emerge, and users might have to switch to it. This is precisely the issue with forks because they often arise when their predecessor simply stops developing and enters a state of stagnation.

[sboesen]

My main message was not that 'Remotely Secure' has not many visible changes for the user compared to 'Remotely Save,' but rather that people generally don't want to delve into details and search for differences between them. That's all.

100% agreed. I think it's possible to create some highlights / screenshots in the readme and better call this out, I definitely agree.

For most people even the security changes are hand-wavy if they don't have an understanding of cryptography. I plan to (at some point) do a writeup on my blog detailing why it's an issue and maybe even share a script that can be used to break the encryption used by Remotely Save to demonstrate the severity of the issue.

Also, we cannot rule out the possibility that you'll cease to support the plugin a year or two from now.

Absolutely! I don't plan to abandon it entirely at any point, so you can expect PRs to be merged or at the very least contributor access being granted to users which have a track record of contributing PRs and are "trusted", which will hopefully mitigate the same fate.

will continue to exist as an independent one.

But if this doesn't happen after a lot of time and development the plugin should probably become standalone.

I still don't see any perk of being a standalone repo, apart from removing the "fork of remotely save" link in GitHub which doesn't bother me at all. Still an independent plugin as a fork. Let me know if I'm wrong, though!

[sboesen]

BTW the name change has been submitted to Obsidian, from Remotely Secure -> Remotely Sync and I'm going to stick with this one. Greatly appreciate the feedback/suggestions for names! Need to make a decision quickly as it's a blocker for submitting a production application with Dropbox and they've lit a fire as we won't be able to integrate new users with Dropbox in approx. 13 days.

[MartinJDavis93]

As for autonomy and independence, I probably attribute slightly different meanings to these terms. It's not about removing mentions that this plugin is a fork and it's based on 'Remotely Save', not at all, it's more about the plugin just taking the course as a stand-alone and from now on it's really a stand-alone product and its merging with 'Remotely Save' or being absorbed by 'Remotely Save' simply becomes irrelevant. Of course, certain fixes can be transferred from one to the other, as with all other forks, but this won't affect their autonomy and separateness.

[MartinJDavis93]

BTW the name change has been submitted to Obsidian, from Remotely Secure -> Remotely Sync and I'm going to stick with this one. Greatly appreciate the feedback/suggestions for names! Need to make a decision quickly as it's a blocker for submitting a production application with Dropbox and they've lit a fire as we won't be able to integrate new users with Dropbox in approx. 13 days.

'Remotely Sync' is, of course, better than 'Remotely Secure', but synchronization means that it's remote. 'ObSync' sounded like a pretty good option, but already.

[MartinJDavis93]

I'm closing this issue, as the name has been changed and there is no longer any point in keeping this issue open.

[MartinJDavis93]

@sboesen Please tell me, currently, the plugin when searching is still displayed as 'Remotely Secure', and I see that the folder for the plugin is automatically created exactly 'remotely-secure'. The Obsidian team hasn't yet processed your request to change the name, or will it remain this way? Because this is likely to cause confusion for new users. Moreover, I already have such cases, which is why I'm asking you 😄

[kadisonm]

Hi, I believe the pull request to change names is still open. To make sure the plugin can still be installed through Obsidian, the manifest id has to match the one on the Obsidian github repo for now #54

[kadisonm]

I might have this backwards since it's a bit confusing. Check also with Sboesen what's going on with the id's.

[sboesen]

@sboesen Please tell me, currently, the plugin when searching is still displayed as 'Remotely Secure', and I see that the folder for the plugin is automatically created exactly 'remotely-secure'. The Obsidian team hasn't yet processed your request to change the name, or will it remain this way? Because this is likely to cause confusion for new users. Moreover, I already have such cases, which is why I'm asking you 😄

100%, as @kadisonm mentioned the pull request is still open - I dropped a message in the Obsidian discord a few days ago because I was also wondering on the status but didn't get a response. Hopefully this confusion is resolved soon!

[MartinJDavis93]

@kadisonm, @sboesen Thanks for your responses. Yes, it's all working, the id is correct because otherwise updating the plugin would have to be done manually. However, I was specifically interested in the current status, so I decided to ask because I think the author has the most information about it. Because at the moment it's all very funny, you tell people that the plugin is 'Remotely Sync', and they say there's no such thing, only 'Remotely Save' and 'Remotely Secure'. You tell them to install 'Remotely Secure', they go directly to the installation page, and there it's already called 'Remotely Sync'. They install it and get the 'Remotely Sync' plugin in the 'remotely-secure' folder, go to plugin authorization in the cloud service, and authorize 'Remotely Secure' 😅 So, for now, it's a complete mess. For outsiders who are not aware of this story, it probably looks very strange. Well, let's hope that by the new year, the Obsidian team will be able to consider and approve your request 😄

[sboesen]

Hundred percent, and of course Dropbox forced us to apply for non development status which required a name (and can't change it) - but then we're only partially swapped. It is a mess, agreed

[fyears]

Hi everyone, remotely-save author here.

Here are some thoughts I would like to share, especially why the naming decision I originally made in point 3: https://github.com/sboesen/remotely-sync/discussions/76

[MartinJDavis93]

@sboesen Finally, request #2737 is closed, and the plugin has been accordingly renamed to Remotely Sync.

Now it's preferable that you make the necessary changes from your side for the final alignment of names and complete migration from Remotely Secure to Remotely Sync.

[sboesen]

Made more changes ^ but some of the references will stay for backwards compatibility. Some of the sync folders appear to also still be Remotely Secure, and it'll be confusing but not sure how to recreate it without forcing users to re-link the app (for example in Dropbox). Hope that's good enough!

[MartinJDavis93]

Made more changes ^ but some of the references will stay for backwards compatibility. Some of the sync folders appear to also still be Remotely Secure, and it'll be confusing but not sure how to recreate it without forcing users to re-link the app (for example in Dropbox). Hope that's good enough!

I think from the very beginning it was clear that when changing the name, reinstallation, and authorization would be unavoidable. That's why one of my first opened issues was related to the name change to do it from the very beginning when there weren't many users to minimize inconveniences. And this is the necessary step, just like it would be when changing some libraries, certificates, etc. This isn't the moment to cling to name compatibility and continue creating chaos with names. And in general, it's advisable to reauthorize precisely, which is what I did to connect the sync service plugin with the correct name. Accordingly, the synchronization folder name also changes to "remotely-sync". This ensures that it doesn't disconnect on its own during a critical moment due to name mismatch.

Also, perhaps when changing the name, it's worth transitioning to version 0.5.0 to indicate that when upgrading from previous versions to version 0.5 and newer, the plugin needs to be reinstall and reauthorize. Maybe it's worth releasing version 0.4.32 and version 0.5.0 in parallel, and for version 0.4.32, keep the old id as "remotely-secure" and add an announcement in the style of "Excalidraw" after the update, stating that for future updates, it's necessary to reinstall the plugin and reauthorize. The new version 0.5.0 is already available! This will inform all current users.

P.S. I can see you are getting confused with the names yourself. For example, in the Readme, "Remotely Save" should be replaced with "Remotely Sync" because some security improvements have been made specifically for "Remotely Sync" 😉

And in general, regarding the new changes to the Readme, I wanted to open a separate issue because they are very strange. I just didn't have time for it, and then I decided not to do it at all and not waste time on it. You're the author, you know better. But since I started, I'll outline two main points that are just extremely strange.

1. "If you want stability, go with Remotely Save!". The lack of updates for "Remotely Save" ≠ stability in the broad sense. It's like claiming that Windows 7 is more stable than new, current, supported versions. It's just abandoned. I understand if the updates were come out but slowly and cautiously when the author has free time for it, but as the author confirmed of "Remotely Save" confirmed, he just abandoned it. So, it's not about stability in the broader sense. Moreover, "Remotely Save" even labels releases as "Pre-release".

2. Now, judging by the Readme, at least for me, it seems that "Remotely Sync" is just a testing ground for "Remotely Save" because: "Note that some of the features will be merged into "Remotely Save" over time", and "Remotely Sync" itself "Is likely less stable at any point in time". It's the same as in the first point. "Remotely Save" hasn't been updated for a year and a half, and until this changes, it's not even worth mentioning.

As for me, it's enough to simply state that "Remotely Sync" is a fork of "Remotely Save", which is developing parallelly and independently and has certain changes compared to the original "Remotely Save". And let the user try to determine independently which plugin is more useful for them.

[fyears]

@MartinJDavis93

abandoned

Hi thanks for your concern about remotely-save. But I am the author of remotely-save and I should point out that your statement about “remotely-save is abandoned” is absolutely wrong and I have never said or planned that. Actually I am going to release a new version in a few days.

Moreover, "Remotely Save" even labels releases as "Pre-release".

That’s not even an issue since I could easily change this label and I believe users are more concerned about the actual robustness and security rather than a visual label.

The lack of updates for "Remotely Save" ≠ stability in the broad sense

I cannot claim anything of remotely-{secure,sync} . But I try my best to keep a clean design and a conservative attitude to functionality of remotely-save, and I try to achieve the robustness by adding many tests and having many design docs.

And @sboesen you are always welcome to contribute prs, let’s build a/two amazing sync tools on Obsidian together !

[kadisonm]

In my opinion Remotely Save is definitely more stable and Remotely Sync is more like a testing ground for it, which isn't a bad thing. It means they can both improve off each other. They will just attract different audiences.

[MartinJDavis93]

Hi thanks for your concern about remotely-save. But I am the author of remotely-save and I should point out that your statement about “remotely-save is abandoned” is absolutely wrong and I have never said or planned that. Actually I am going to release a new version in a few days.

The word "abandoned" has several meanings. It was meant that you simply left the development of the project untouched for essentially 1.5 years (and possibly for an even longer duration, until the release of a new version), meaning you consciously didn't pay attention to it. As you yourself noted, "I haven't paid attention to the development for a long while...". It's great that you plan to release a new version, but I go by the dry facts, and considering your own words, until you release a new version, the project remains in the same "suspended state", meaning it's not progressing. I think at some point, the developers of MPlayer also intended to release a new version, but something didn't work out for them.

That’s not even an issue since I could easily change this label and I believe users are more concerned about the actual robustness and security rather than a visual label.

"That's not even an issue". I disagree with this. It's precisely the issue. "I could easily change this label" is great that you could, but you chose the label you chose. Let's assume I'm an average user, and the label indicates to me how stable the author considers their product. That's why various labels are introduced. If I see two similar products with labels "Latest" and "Pre-release", for me, the "Latest" one would seem more stable, and for stability, I would choose it. To reach "actual robustness and security", you first have to choose "Pre-release". The label "Pre-release" itself inspires less trust. That's the essence of the problem.

I cannot claim anything of remotely-{secure,sync} . But I try my best to keep a clean design and a conservative attitude to functionality of remotely-save, and I try to achieve the robustness by adding many tests and having many design docs.

And @sboesen you are always welcome to contribute prs, let’s build a/two amazing sync tools on Obsidian together !

At this stage, "Remotely Sync" doesn't differ significantly from "Remotely Save", and the "clean design" hasn't been compromised in any way. If you read this thread from the beginning, you'll see that I suggested merging "Remotely Sync" with "Remotely" Save from the very beginning to avoid creating forks because it's also a problem for an average user.

In general, if I understand correctly, "Remotely Sync" is precisely the result of ignoring open Sboesen pull requests.

I'll quote a few of my statements here to avoid describing everything again.

"Overall, I don't know the whole history. I assume you've already tried to contact the developer of 'Remotely Save' (formerly fyears, and the repository was directly linked to him, now I see it's a separate repository called remotely-save). It would be great not to create forks but to contribute all your changes to 'Remotely Save', so that everyone benefits. Your improvements don't contradict the idea of 'Remotely Save'; they are simply enhancements. You could just join the 'Remotely Save' team, gaining access to the repository, and together you could support it, without creating fork. A larger team has more chances for further improvements."

"I understand that if 'Remotely Save' was developing now, then a fork of 'Remotely Secure' would be created only in the event that the authors' development vector didn't match. And since 'Remotely Save' hasn't been updated for a long time, creating 'Remotely Secure' is essentially just a way to continue developing the same 'Remotely Save', but with a different developer and under a different name. 'Remotely Save' has other forks, from which you probably took fixes. So, in my opinion, everyone involved in developing forks, including the original authors of 'Remotely Save', would be better off uniting in one repository and collectively working on fixes and the development of the plugin as their free time allows. It's just more productive in the end, even if participants only occasionally contribute fixes. I doubt that the global development differences among all authors are significant. I think all implementations are based either on personal needs or community requests. Therefore, everyone can develop the direction they consider necessary and merge it all into one product. The end user only benefits from all this because they no longer have to choose between all these forks, where one has some cool parameter but lacks the useful parameter found in another fork.

Of course, uniting is always a complex problem. But it was worth a try. If it worked, everyone would benefit from it."

[MartinJDavis93]

In my opinion Remotely Save is definitely more stable and Remotely Sync is more like a testing ground for it, which isn't a bad thing. It means they can both improve off each other. They will just attract different audiences.

Do you have stability issues with Remotely Sync?)

[kadisonm]

Do you have stability issues with Remotely Sync?

Yep, but I understand that this plugin is adding a lot of features in a short time. The only reason I say Remotely Sync is a huge improvement to me is that it has some features that I was personally looking for. This doesn't mean I think Remotely Sync is more stable though.

I'm personally okay with the instability and waiting for bug fixes and features, but for the general user who wants a working solution 90% of the time, Remotely Save is the more stable option.

[MartinJDavis93]

Do you have stability issues with Remotely Sync?

Yep, but I understand that this plugin is adding a lot of features in a short time. The only reason I say Remotely Sync is a huge improvement to me is that it has some features that I was personally looking for. This doesn't mean I think Remotely Sync is more stable though.

I'm personally okay with the instability and waiting for bug fixes and features, but for the general user who wants a working solution 90% of the time, Remotely Save is the more stable option.

"Yep" is the most general answer, can you be more specific? What kind of stability issues are present in "Remotely Sync" but not present in "Remotely Save"? I didn't notice any globally in my scenario. The current version of Remotely Sync 0.4.31 is as stable as Remotely Save 0.3.25. They are both stable, it's just that "Remotely Sync" solves for me those problems that weren't solved by requests "Remotely Save". As I've mentioned more than once, many of my friends/acquaintances now use "Remotely Sync", so I've a certain sample regarding the stability of "Remotely Sync" on the two services for sync Dropbox and OneDrive. Therefore, it's interesting what kind of stability issues have befallen you?)

[kadisonm]

I usually open an issue for most of them and wait it out, you can check those but I'd rather not get more specific as this seems kind of trivial.

Also I'm sure some of the issues discovered here have been discovered in Remotely Save or just became more apparent because of new features like the sync status as well.

[MartinJDavis93]

I usually open an issue for most of them and wait it out, you can check those but I'd rather not get more specific as this seems kind of trivial.

Also I'm sure some of the issues discovered here have been discovered in Remotely Save or just became more apparent because of new features like the sync status as well.

Perhaps, that's where it should have started – that most issues and problems were inherited from Remotely Save and are common. Regarding the issues reports you've opened, it's a normal situation. Take a look at the open bug list for Remotely Save. Therefore, talking about improved, excessive stability for Remotely Save at this stage seems pulled by the ears. No changes have been made to Remotely Save for a long time, so nothing broke. That's all. But it's not about stability in the broad sense, when you are, for example, Debian, and you make changes slowly and deliberately over a long period.

[MartinJDavis93]

@fyears

I don't really want to clutter this topic, even though it's closed, but it has nothing to do with all our discussions. However, since you've mentioned that you're planning to release a new version, I decided to provide a list of all the fixes that I consider useful and that, in my opinion, should be included in Remotely Save.

1. "Transition from 8 notifications to 2" #15. It's not very noticeable when you only use Remotely Save and have nothing to compare it to. However, when you've been using Remotely Sync for a while, where notifications are condensed to two main ones – the start of sync and its completion (or error) – you'll understand that displaying an additional +6 notifications with sync stages is essentially white noise that doesn't provide any everyday benefit but is rather annoying. It seems to me that, at some point, Remotely Save also switched to 2 notifications but quickly returned to 8, correct me if I'm wrong. Using 8 notifications can be useful for debugging to understand at which sync stage a particular failure is occurring without delving into the console. However, for everyday use, they aren't necessary for regular users. In summary, I'd like to have the option to use only 2 basic notifications, as it's currently in Remotely Sync. If you consider 8 notifications with sync stages useful and think it should be the default, it would be good to have a toggle in the settings to disable it, and then only 2 basic notifications about the start and end of sync would be displayed.

2. "Faster automatic sync" #393, #33. I've explained multiple times why I consider this useful and why many people in my circle use it. It doesn't affect all users until they change this parameter themselves. Therefore, its implementation won't cause any inconvenience to others. Many have noticed that the gap between 30 seconds and 1 minute is quite large, visually noticeable, and the absence of 10 seconds is also noticeable, considering other options for choosing the time for various available parameters. Therefore, the best option for automatic sync would be: 5s, 10s, 15s, 30s, 45s, 1m, 5m, 10m, 15m, 30m. This will settle this issue once and for all. Everyone will be able to choose the parameter that suits them. Although this may slightly increase the size of the list, it's not critical.

3. "Choose where to move deleted files" #394, #34. This has bothered me throughout all these years of use, but Sboesen managed to solve it, thanks to him for that. So, you just need to transfer this feature to Remotely Save as well.

4. "Sync on Save". A great feature, it was already there when I tried Remotely Sync, and it works great. So, you just need to transfer this feature to Remotely Save as well.

5. "Sync In Status Bar". Personally, I don't use it because the flashing during each sync distracts focus. But judging by various discussions, some people use it. Currently, there are several open issues related to it #68, #46. But, despite all this, many would like to see it in Remotely Save as well, so I think you should transfer it.

6. "Sync Obsidian bookmarks". I don't use bookmarks, but I think this implementation is useful for those who use them. So, you just need to transfer this feature to Remotely Save.

7. "Sync trash bins" #37. I requested this feature. So far, it doesn't work with Dropbox or OneDrive, at least for me and more than 20 other users. Maybe it works for someone with S3 or when "Sync Config Dir" is additionally enabled, I don't know. If it works for someone, let me know, and then it might be worth transferring. At this stage, I think it's not worth transferring in its current form.

8. Іssue #40. It's not fixed, but I think you should also pay attention to it because it generates other problems, which can be seen through references to it.

Of course, there are various internal fixes, such as encryption, which should probably also be transferred. I only noted the changes that are on the surface, are common, and every user can see.

[sboesen]

@MartinJDavis93 thanks for sharing your thoughts & concerns. I don't think forcing reauthorization by deleting the current plugin with third party providers is helpful - from what you described new app authorizations will use the new name. I'm not convinced there is really any chaos with having some small number of users having differing app folder names. I could be wrong, though! Definitely curious what specifically you think is concerning given almost all visible references to "Remotely Secure" have been updated.

P.S. I can see you are getting confused with the names yourself. For example, in the Readme, "Remotely Save" should be replaced with "Remotely Sync" because some security improvements have been made specifically for "Remotely Sync" 😉

I think my wording might be confusing you here, but I don't think this statement is incorrect (though maybe could be reworded, happy to take suggestions). This is a fork of Remotely Save with some security improvements & feature additions. We took Remotely Save and added stuff - that is the wording as is.

The encryption change is the largest and doesn't support backwards compatibility, meaning there are some changes at the very least which probably won't be ported as-is to Remotely Save. Then there's the fact that @fyears may not want all of features we implement here, it's up to them in the end what gets merged in the main plugin and you have to focus more on stability when you have the number of users Remotely Save has.

@fyears more than happy to link some commits for features you're interested in & collaborate on others that are WIP!

I'm personally okay with the instability and waiting for bug fixes and features, but for the general user who wants a working solution 90% of the time, Remotely Save is the more stable option.

@kadisonm agreed - we've had releases where things break for certain providers due to limitations and we don't use beta testing. Remotely Sync is more "move fast and break things + then fix them quickly" which isn't for everyone, and per discussion with @fyears some features or updates might be migrated to Remotely Save when they are more stable.

[MartinJDavis93]

@MartinJDavis93 thanks for sharing your thoughts & concerns. I don't think forcing reauthorization by deleting the current plugin with third party providers is helpful - from what you described new app authorizations will use the new name. I'm not convinced there is really any chaos with having some small number of users having differing app folder names. I could be wrong, though! Definitely curious what specifically you think is concerning given almost all visible references to "Remotely Secure" have been updated.

The plugin named Remotely Sync in the remotely-secure folder – it's bad. That's all. I've nothing more to add here. If it's okay for you, I don't see the point in continuing to explain anything further.

I think my wording might be confusing you here, but I don't think this statement is incorrect (though maybe could be reworded, happy to take suggestions). This is a fork of Remotely Save with some security improvements & feature additions. We took Remotely Save and added stuff - that is the wording as is.

A direct quote from the Readme: "Some security improvements were made to Remotely Save".

• Were these security improvements accepted and included in Remotely Save?
• No.

Most likely, you actually developed them specifically for Remotely Save, but as you mentioned in the Readme that "the Remotely Save plugin was not actively maintained", these security improvements were included in Remotely Sync, but not in Remotely Save. At least for now

The encryption change is the largest and doesn't support backwards compatibility, meaning there are some changes at the very least which probably won't be ported as-is to Remotely Save. Then there's the fact that @fyears may not want all of features we implement here, it's up to them in the end what gets merged in the main plugin and you have to focus more on stability when you have the number of users Remotely Save has.

As I mentioned earlier, I don't use encryption. Therefore, changes regarding it personally don't interest me. If @fyears considers some of the changes useful, let him include them.

@fyears more than happy to link some commits for features you're interested in & collaborate on others that are WIP!

I provided a separate list of all the desired features and innovations that have already been implemented and tested to some extent above, with an explanation of why I find it useful. As far as I'm concerned, that's enough.

@kadisonm agreed - we've had releases where things break for certain providers due to limitations and we don't use beta testing. Remotely Sync is more "move fast and break things + then fix them quickly" which isn't for everyone, and per discussion with @fyears some features or updates might be migrated to Remotely Save when they are more stable.

The sync service is clearly not the product where one can talk about beta testers. I don't know anyone who would voluntarily want to test a sync service and subscribe to beta channels. The sync service simply has to perform one function – synchronization. All other additional features are minor and relate to parameters for its more correct, individual operation. The best sync service – is an inconspicuous sync service (such as Google Keep) which simply performs its direct function. But since Remotely Save/Remotely Sync this isn't the official sync service of the product, various nuances and additional settings appear to tweak its operation.

Certainly, during new implementations, certain nuances or problems may arise, and sometimes something may even break, but this is a normal situation for all types of products that are updated and developed. The speed of reaction to the problem is important here. Therefore, after each update, it would be ideal to track the bug list for a couple of days for any possible critical bugs.

P.S. Microsoft finally fixed the issue with the File Explorer that appeared on the screen randomly. It took them 15 months. As for the number of user complaints about this, I'd better not mention it 😉