Community driven maintenance

[6543]

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]

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

[6543]

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

[fm-sys]

@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:

[6543]

@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]

@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]

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]

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]

@RobinLinus gendle ping?

[6543]

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

[danperks]

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

[Bellisario]

I would be up, too!

[tomh4]

I could help with the hosting

[RobinLinus]

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]

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]

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]

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]

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]

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

[fm-sys]

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]

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]

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]

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]

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:
websockets/ws#1354 (comment)

Anyway, these errors should not crash the server because handled:
websockets/ws#1354 (comment)

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]

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

[schlagmichdoch]

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:

• iOS Private Relay / VPN
  • iPv4 addresses are not the same for all devices on the network
• university networks
  • iPv4 addresses are not the same for all devices on the netwok
• iPv6 addresses
  • devices only connected via iPv6 cannot be grouped via their iPv4 address
• Device on Mobile Hotspot
  • hotspot host and device cannot reach each other

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:

• Snapdrop clear
  • "classic" Snapdrop
  • never add any new button / fancy feature
  • only allow the one primary user workflow
  • only think about the average user
  • primary goal: make it more stable and efficient
  • secondary goal: enable the primary workflow on more configurations (university networks, VPNs, etc.)
• Snapdrop extended
  • think about power users too
  • cleanly implement network transfer, rooms etc. for those who would benefit from it
  • Only implement features after thoroughly discussing them in the community
  • host it on separate server or as subdomain like extended.snapdrop.net
  • before even thinking about adding a feature to Snapdrop clear it could be thoroughly tested here

[schlagmichdoch]

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]

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

[schlagmichdoch]

@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:

• Snapdrop server
• Snapdrop clear - frontend
• Snapdrop extended - frontend
• (apps, implementations etc.)

[6543]

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