search

RobinLinus / snapdrop

A Progressive Web App for local file sharing
https://snapdrop.net
GNU General Public License v3.0
17.68k stars 1.62k forks source link

Community driven maintenance #333

Open 6543 opened 2 years ago

6543 commented 2 years ago

Since I discovered it, I really like using it. Compared to the size of this project there is unfortunately not much maintenance activity.

So I propose to move snapdrop to it's own organization and let it be Community driven.

I reserved organization (so we don't have issues to get it stolen by some random person) name 'SnapDrop' and would move ownership to you @RobinLinus so you can move this repo into it.

Since this is your project in the first place you finally have to decide ... happy to hear your response :)

crapStone commented 2 years ago

This could also be a opportunity to move all community "forks" to a central organization (e.g. desktop app, Android app, ...).

6543 commented 2 years ago

Update: Org 'SnapDrop' is now owned by @RobinLinus

fm-sys commented 2 years ago

@6543 have you discussed this with @RobinLinus?

I would be fine with moving my android client fm-sys/snapdrop-android into a global snapdrop organization, but this does only make sense for sure if the 'main repo' is in there as well...

BTW, please rename the org to 'Snapdrop' (only first character capitalized). That's the way how this service is named at all places. See e.g. https://github.com/RobinLinus/snapdrop/blob/master/README.md or:

grafik

6543 commented 2 years ago

@fm-sys I told him that he could contact me if he had any questions. - the org is now completely owned by him I have no control anymore :)

dumblob commented 2 years ago

@RobinLinus could you give admin rights in the GitHub org to all maintainers of apps using/interacting_with Snapdrop?

This feels like an unsafe move but with a high chance that the community will move forward faster. I did the same with some of my projects once I didn't have time to maintain them fast enough.

fm-sys commented 2 years ago

Hm, seems like this doesn't went in the way we would have expected it :-/

Nearly half a year has passed without any progress...

6543 commented 2 years ago

well yes - but there is no huge dev community out there too :/

-> https://github.com/RobinLinus/snapdrop/graphs/contributors?from=2021-01-01&to=2021-12-31&type=c

6543 commented 2 years ago

@RobinLinus gendle ping?

6543 commented 1 year ago

... #415, #492, #500, #505, #507 ...

danperks commented 1 year ago

I would be up for assisting in the maintenance of this, if that's of any help.

Bellisario commented 1 year ago

I would be up, too!

tomh4 commented 1 year ago

I could help with the hosting

RobinLinus commented 1 year ago

Ok, will think about community-driven maintenance. My main issue with it is that I built Snapdrop to use it myself and it is quite perfect for what I need it. There are plenty of other full-featured file-sharing websites out there and I don't want to replicate them. People in the community have already added to Snapdrop a dark mode and an image preview, which aren't really strong features in my eyes. This is in conflict with the philosophy of simplicity behind Snapdrop. I don't want to see Snapdrop suffering from being overloaded with all kinds of mediocre features that dilute its core value proposition. Snapdrop should be extremely simple, clean, and easy to use. So, if I would ever give Snapdrop away then only to people who really get simplicity. E.g. what I would love to see is Snapdrop being more stable and faster. If you want to work on that please reach out to me! It would be really great if someone can see why the server crashes so often and fix it.

6543 commented 1 year ago

just put Snapdrop should be extremely simple, clean, and easy to use. as top rio and agenda that maintainers should have in mind when reviewing stuff

fm-sys commented 1 year ago

IMHO new features aren't always bad. However we should be reminded that no single additional click should be added to the primary workflow. Make snapdrop more robust, add wisely choosen and cleanly implemented features (e.g. rooms / network transfer, keyboard shortcuts, just thinking...?) while keeping the primary workflows as simple as it is today. This isn't an impossible task, however requires some clean and thought through UX design.

BTW, I would also be very pleased if I could help maintaining the app. I'm not a good web developer, however I'm the developer of "Snapdrop for Android" and I would really like to actively help in this repo as well, doing e.g. UX reviews and such stuff (always keeping simplicity in mind ;-))

RobinLinus commented 1 year ago

Here's a somewhat oversimplified example of my perspective on how to grow Snapdrop:

Suppose you want to add some fancy feature that would be really nice to have in some situations. Let's assume we could quantify exactly the usefulness of a feature and we could know exactly that for 1 in 20 users the fancy feature increases our product's usefulness by 20%. That's significant. So we should add the fancy feature, right?

That depends a lot on how much the existence of the fancy feature worsens the app's usefulness for the other 95% of users. Because every feature, every button, every option of the app requires some mental effort for all users to process it. Even understanding that you don't need a particular feature requires some effort.

Now suppose our new fancy feature decreases the app's usefulness by 1% for the users who don't use it. So, in total, we'd have 0.05 * 1.2 + 0.95 * 0.99 = 1.0005 meaning we increased the overall usefulness only by 0.05% with the new feature. If the fancy feature would decrease the app's usefulness for the people who don't use it by just by 1.1% instead of 1% then it would already reduce the app's overall usefulness. Adding the fancy feature would be a net negative. This does not yet take into account that we also have to maintain the fancy feature and we have to deal with all ways its code might interfere with all other feature's code.

If, in contrast, we invest the time instead into the less glorious tasks like making Snapdrop more stable and faster, then we can actually increase the usefulness of the app by a couple percent for the large majority of users. So the impact here is like 100x higher than the fancy feature.

fm-sys commented 1 year ago

Interesting thought, thanks for explaining. I can really good understand why you want to keep it simple... I don't like apps as well, which simply implement everything which is theoretically possible. Snapdrop should stay a simple-to-use tool for file-sharing and not more than that.

Making Snapdrop more stable and faster would definitely be great and should have the biggest priority!

RobinLinus commented 1 year ago

So if someone wants to find out why the server crashes so often and fix it, please go for it!

fm-sys commented 1 year ago

So if someone wants to find out why the server crashes so often and fix it, please go for it!

Are there any log files which might be helpful?

tomh4 commented 1 year ago

Yes, can you share some logs? Or if not, can we implement something on the server for logging ? So we can inspect future crashes

RobinLinus commented 1 year ago

Ok, let me see if I can find helpful logs.

Is someone here interested to port the server to Rust? I guess that would make it much more stable and efficient.

RobinLinus commented 1 year ago

This is from the server's log file: 

snapdrop.service failed.
Oct 13 13:06:22 systemd[1]: Unit snapdrop.service entered failed state.
Oct 13 13:06:22 systemd[1]: snapdrop.service: main process exited, code=exited, status=1/FAILURE
Oct 13 13:06:22 node[21049]: }
Oct 13 13:06:22 node[21049]: [Symbol(status-code)]: 1002
Oct 13 13:06:22 node[21049]: at processTicksAndRejections (node:internal/process/task_queues:83:21) {
Oct 13 13:06:22 node[21049]: at emitErrorCloseNT (node:internal/streams/destroy:158:3)
Oct 13 13:06:22 node[21049]: at emitErrorNT (node:internal/streams/destroy:193:8)
Oct 13 13:06:22 node[21049]: at Receiver.emit (node:events:394:28)
Oct 13 13:06:22 node[21049]: at Receiver.receiverOnError (/srv/snapdrop/server/node_modules/ws/lib/websocket.js:8
Oct 13 13:06:22 node[21049]: Emitted 'error' event on WebSocket instance at:
Oct 13 13:06:22 node[21049]: at readableAddChunk (node:internal/streams/readable:287:9)
Oct 13 13:06:22 node[21049]: at addChunk (node:internal/streams/readable:312:12)
Oct 13 13:06:22 node[21049]: at Socket.emit (node:events:394:28)
Oct 13 13:06:22 node[21049]: at Socket.socketOnData (/srv/snapdrop/server/node_modules/ws/lib/websocket.js:909:35
Oct 13 13:06:22 node[21049]: at Receiver.Writable.write (node:internal/streams/writable:334:10)
Oct 13 13:06:22 node[21049]: at _write (node:internal/streams/writable:330:10)
Oct 13 13:06:22 node[21049]: at writeOrBuffer (node:internal/streams/writable:389:12)
Oct 13 13:06:22 node[21049]: at Receiver._write (/srv/snapdrop/server/node_modules/ws/lib/receiver.js:78:10)
Oct 13 13:06:22 node[21049]: at Receiver.startLoop (/srv/snapdrop/server/node_modules/ws/lib/receiver.js:131:22)
Oct 13 13:06:22 node[21049]: at Receiver.getInfo (/srv/snapdrop/server/node_modules/ws/lib/receiver.js:171:14)
Oct 13 13:06:22 node[21049]: RangeError: Invalid WebSocket frame: RSV2 and RSV3 must be clear
Oct 13 13:06:22 node[21049]: ^
Oct 13 13:06:22 node[21049]: throw er; // Unhandled 'error' event

Looks like this Invalid WebSocket frame: RSV2 and RSV3 must be clear error occurs a lot.

Bellisario commented 1 year ago

This is from the server's log file:

snapdrop.service failed.
Oct 13 13:06:22 systemd[1]: Unit snapdrop.service entered failed state.
Oct 13 13:06:22 systemd[1]: snapdrop.service: main process exited, code=exited, status=1/FAILURE
Oct 13 13:06:22 node[21049]: }
Oct 13 13:06:22 node[21049]: [Symbol(status-code)]: 1002
Oct 13 13:06:22 node[21049]: at processTicksAndRejections (node:internal/process/task_queues:83:21) {
Oct 13 13:06:22 node[21049]: at emitErrorCloseNT (node:internal/streams/destroy:158:3)
Oct 13 13:06:22 node[21049]: at emitErrorNT (node:internal/streams/destroy:193:8)
Oct 13 13:06:22 node[21049]: at Receiver.emit (node:events:394:28)
Oct 13 13:06:22 node[21049]: at Receiver.receiverOnError (/srv/snapdrop/server/node_modules/ws/lib/websocket.js:8
Oct 13 13:06:22 node[21049]: Emitted 'error' event on WebSocket instance at:
Oct 13 13:06:22 node[21049]: at readableAddChunk (node:internal/streams/readable:287:9)
Oct 13 13:06:22 node[21049]: at addChunk (node:internal/streams/readable:312:12)
Oct 13 13:06:22 node[21049]: at Socket.emit (node:events:394:28)
Oct 13 13:06:22 node[21049]: at Socket.socketOnData (/srv/snapdrop/server/node_modules/ws/lib/websocket.js:909:35
Oct 13 13:06:22 node[21049]: at Receiver.Writable.write (node:internal/streams/writable:334:10)
Oct 13 13:06:22 node[21049]: at _write (node:internal/streams/writable:330:10)
Oct 13 13:06:22 node[21049]: at writeOrBuffer (node:internal/streams/writable:389:12)
Oct 13 13:06:22 node[21049]: at Receiver._write (/srv/snapdrop/server/node_modules/ws/lib/receiver.js:78:10)
Oct 13 13:06:22 node[21049]: at Receiver.startLoop (/srv/snapdrop/server/node_modules/ws/lib/receiver.js:131:22)
Oct 13 13:06:22 node[21049]: at Receiver.getInfo (/srv/snapdrop/server/node_modules/ws/lib/receiver.js:171:14)
Oct 13 13:06:22 node[21049]: RangeError: Invalid WebSocket frame: RSV2 and RSV3 must be clear
Oct 13 13:06:22 node[21049]: ^
Oct 13 13:06:22 node[21049]: throw er; // Unhandled 'error' event

Looks like this Invalid WebSocket frame: RSV2 and RSV3 must be clear error occurs a lot.

Seems there are clients sending a wrong message to the server: https://stackoverflow.com/a/45304511/14997578

Could also be intentional to crash the server: https://github.com/websockets/ws/issues/1354#issuecomment-404613275

Anyway, these errors should not crash the server because handled: https://github.com/websockets/ws/issues/1354#issuecomment-774617470

For a "dirty" fix (while we understand better the problem), the server could be managed using pm2 for auto-restart on crash and logs saving on crash: https://stackoverflow.com/a/37701099/14997578

RobinLinus commented 1 year ago

Thanks @Bellisario, looks like this line helps: https://github.com/RobinLinus/snapdrop/blob/master/server/index.js#L33

schlagmichdoch commented 1 year ago

Any news? Server is down again. Could we do another community driven debugging session?

well yes - but there is no huge dev community out there too :/

-> https://github.com/RobinLinus/snapdrop/graphs/contributors?from=2021-01-01&to=2021-12-31&type=c

I guess this is also the case because pull requests are neither merged nor reacted upon and there is no overall plan or any label system what needs to be implemented.

Regarding the overall topic: I understand the approach of keeping everything extremly simple very well. I guess noone here likes feature creep and whatever comes out of this discussion, Snapdrop should always only be about file and message sharing and keep this extremly simple.

Personally I really like Snapdrop and have used it nearly daily for many years. Sadly Snapdrop does not work with some technologies eventhough devices are on the same network. Information about limitations of Snapdrop is not presented to the user. I would really love some development to make the primary workflow work for the following scenarios:

Apart from that, I believe cleanly implemented features like transfer accross networks, permanent rooms and shortcuts would be able to increase productivity if done right. I really think there are many people who would like to extend Snapdrop to rely on it whenever they want to share files / messages between two devices without any intermediary.

Nevertheless, I aggree that is not the case for all users. Therefor, I would suggest to split Snapdrop along the following lines:

schlagmichdoch commented 1 year ago

or a "dirty" fix (while we understand better the problem), the server could be managed using pm2 for auto-restart on crash and logs saving on crash:

Wouldn't a self restarting and logging docker be sufficient too? I don't understand why the server is not even responding to pings when only the snapdrop.service is down. Is the whole server offline?

dumblob commented 1 year ago

@schlagmichdoch maybe create a separate GitHub/Codeberg organization instead of a private repo?

schlagmichdoch commented 1 year ago

@dumblob Sure, whatever structure fits best! My suggestion is simply, that there could be multiple official Snapdrop instances with various feature sets, to preserve the really simple and clear UX/UI of the current Snapdrop but offer an extended version as well. Idealy they would all talk to the same backend (e.g. server.snapdrop.net instead of snapdrop.net/server as it is now) to make peers visible to peers on different instances.

GitHub/Codeberg organisation:

6543 commented 12 months ago

new candidate for this issue might be https://github.com/schlagmichdoch/pairdrop ...