문제는 이런 대안들이 전부 같은 로컬 네트워크에 있어야 한다는 데 있음
Airdrop의 좋은 점은 그 로컬 네트워크를 뒤에서 자동으로 만들고 처리해준다는 점이라고 이해하고 있음
그래서 친구들과 하이킹 중이어도 바로 뭔가 보낼 수 있었음
Android로 바꾼 뒤에는 친구 기기에 테더링해서 LAN을 만든 다음 Localsend를 쓰고 있는데, 경험 자체는 훨씬 덜 매끄러움
https://mbarlow.github.io/thinair/
그냥 정적 GitHub 페이지로 동작하는 device-to-device 전송 도구임
gh repo: https://github.com/mbarlow/thinair
각 기기가 스캔할 QR 코드를 만들고, WebRTC 연결을 잡음
Android끼리는 서로 QR 모드에서 카메라 스캔 모드로 전환하라고 알려주는 오디오 chirp도 씀
Android↔Apple도 테스트해봤고 동작하긴 하는데, Apple은 그 오디오 chirp를 못 잡음
그럴 때는 조금 기다리면 QR 코드가 사라져서 스캔 단계로 넘어갈 수 있음
급하게 만든 거고, 원래는 새소리 같은 chirp나 옛날 모뎀 방식으로 스마트폰끼리 오디오 핸드셰이크를 실험해보고 있었음
폰을 맞대고 오디오 프레임을 주고받으며 전송 시작을 확인하는 건 재미있었지만, 핸드셰이크가 느리고 신뢰성도 낮았음
흐름을 더 다듬고 싶고, 지금은 iPhone/Android/PC 사이에서 앱, 이메일, 계정 없이 파일 보낼 때 이미 쓰고 있음
Airdrop도 꽤 이상하게 동작할 때가 있음
다른 폰을 못 찾는 경우가 있고, 아마 이전 전송이 백그라운드에서 조용히 실패했을 때 그런 듯함
모바일/Wi-Fi 연결이 없으면 연락처 검색에도 문제가 있었고, 산에서 다른 폰으로 사진 보내려 할 때 겪었음
가끔은 그냥 멈춰서 아예 안 되기도 해서, 이런 Apple magic은 별로 도움이 안 됨
Localsend는 사실 Airdrop이 하는 일 중 마지막 단계만 해줌
Localsend를 쓰려면 한 기기에서 ad-hoc Wi‑Fi를 만들고, 다른 기기들을 거기에 연결한 다음, 그제야 Localsend를 실행해야 함
앞의 두 단계가 꽤 번거롭고, Airdrop이 그걸 알아서 처리해주니까 훨씬 마찰 없이 느껴지는 것임
최근에 쓰기 시작했는데 정말 잘 동작하고 Airdrop보다 훨씬 믿을 만했음
다만 UX는 더 좋아질 여지가 있음
그래도 Apple이 Airdrop을 좀 고쳐줬으면 좋겠음
쓸 때마다 신뢰가 너무 낮고, 기기를 못 보거나 Mac 사용자가 여러 명이면 같은 Mac을 두 번 보여주면서 어느 사용자인지도 안 알려줘서 헷갈림
다들 이걸 어디에 쓰는지 궁금함
그렇게까지 이런 앱이 필요할 정도로 어떤 큰 파일들을 만들고 옮기는 건지 잘 모르겠음
내 경우 휴대폰에서 생기는 파일은 사진과 영상뿐이고, Immich로 백업한 뒤 링크로 공유하면 됨
보통 사람들도 iCloud나 Google Photos로 비슷하게 할 것 같음
문서 같은 다른 파일 동기화는 ownCloud OCIS를 쓰고 있고, 대부분은 DropBox나 iCloud, 아니면 이메일이나 WhatsApp으로도 충분할 것 같음
로컬 네트워크에서 ISO 같은 걸 옮길 때는 SMB로 복사하면 되고, 사실상 어디서나 되고 별도 앱도 필요 없음
백업이라면 하드 드라이브를 그냥 꽂아도 됨
그래서 왜 이걸 써야 하는지 잘 납득이 안 감
그런 문제들 트러블슈팅은 이미 해봤는지 궁금함
예전엔 나도 비가시성 문제가 있었는데, 요즘은 항상 잘 되는 편임
내 경우엔 기기는 보여도 전송을 시작하면 절반 정도는 상대 기기에 아예 안 뜸
확실하게 고치는 방법은 아직 못 찾았고, 양쪽에서 Airdrop을 껐다 켜는 게 제일 낫긴 한데 그것도 70% 정도만 통함
이건 꼭 써봐야겠음
iPhone과 Linux 데스크톱 사이 전송용으로 Localsend를 깔아뒀는데, 항상 잘 굴러가진 않음
Firewalld에서 Localsend 포트를 열어도 기기끼리 서로 보이기까지 10분 넘게 걸릴 때가 있음
브라우저 기반이면 최소한 discovery는 더 빠를 것 같음
비슷한 형태의 걸 Tauri로 내본 적이 있음
설치 파일 크기는 Mac 약 27MB, Linux .deb 45MB, Windows 53MB 정도였고, Electron은 바닥이 150MB쯤 됐음
.AppImage만 예외적으로 110MB 정도인데 런타임을 번들하기 때문임
이 크기 절감은 OS의 webview를 재사용해서 나오지만, 그게 동시에 비용이기도 함
Linux의 WebKitGTK는 Mac WebKit이나 Windows Edge WebView와 진짜 다르게 굴러가서, Chromium이 대신 처리해주던 걸 못 받고 크로스플랫폼 디버깅에 시간을 쓰게 됨
의외로 더 놀라웠던 건 프레임워크보다 Linux 패키징이었음
AppImage는 어디서나 돌아가지만 대부분 사용자에게는 2등 시민처럼 느껴지고, .deb는 주류 배포판을 커버하지만 계속 움직이는 glibc 버전을 따라가야 함
Snap/Flatpak은 공식적인 cross-distro 답안처럼 보이지만, 샌드박스와 권한 처리 때문에 인디 개발자는 몇 주를 태우기 쉬움
결국 .deb와 .AppImage를 배포했더니 몇 시간 안 돼서 "왜 AUR엔 없냐"는 메일이 오기 시작했음
내 쪽에서는 이게 안 됐음
Firefox, Chrome, 휴대폰, 노트북으로 송수신 다 해봤음
콘솔엔 WebRTC: ICE failed, add a TURN server and see about:webrtc for more details.가 떴고, 이걸 사용자가 어떻게 해결해야 할지는 잘 모르겠더라
검색해보면 대부분 개발자용 조언뿐이었음
결국 알아냈는데, Tailscale을 끄면 동작함
Hacker News 의견들
문제는 이런 대안들이 전부 같은 로컬 네트워크에 있어야 한다는 데 있음
Airdrop의 좋은 점은 그 로컬 네트워크를 뒤에서 자동으로 만들고 처리해준다는 점이라고 이해하고 있음
그래서 친구들과 하이킹 중이어도 바로 뭔가 보낼 수 있었음
Android로 바꾼 뒤에는 친구 기기에 테더링해서 LAN을 만든 다음 Localsend를 쓰고 있는데, 경험 자체는 훨씬 덜 매끄러움
그냥 정적 GitHub 페이지로 동작하는 device-to-device 전송 도구임
gh repo: https://github.com/mbarlow/thinair
각 기기가 스캔할 QR 코드를 만들고, WebRTC 연결을 잡음
Android끼리는 서로 QR 모드에서 카메라 스캔 모드로 전환하라고 알려주는 오디오 chirp도 씀
Android↔Apple도 테스트해봤고 동작하긴 하는데, Apple은 그 오디오 chirp를 못 잡음
그럴 때는 조금 기다리면 QR 코드가 사라져서 스캔 단계로 넘어갈 수 있음
급하게 만든 거고, 원래는 새소리 같은 chirp나 옛날 모뎀 방식으로 스마트폰끼리 오디오 핸드셰이크를 실험해보고 있었음
폰을 맞대고 오디오 프레임을 주고받으며 전송 시작을 확인하는 건 재미있었지만, 핸드셰이크가 느리고 신뢰성도 낮았음
흐름을 더 다듬고 싶고, 지금은 iPhone/Android/PC 사이에서 앱, 이메일, 계정 없이 파일 보낼 때 이미 쓰고 있음
다만 아주 안정적이거나 친화적인 편은 아님
https://github.com/spieglt/FlyingCarpet
Android 앱이고, 공유할 때 LAN이 필요 없다고 함
https://play.google.com/store/apps/details?id=com.fastfilelink.wrapper
다른 폰을 못 찾는 경우가 있고, 아마 이전 전송이 백그라운드에서 조용히 실패했을 때 그런 듯함
모바일/Wi-Fi 연결이 없으면 연락처 검색에도 문제가 있었고, 산에서 다른 폰으로 사진 보내려 할 때 겪었음
가끔은 그냥 멈춰서 아예 안 되기도 해서, 이런 Apple magic은 별로 도움이 안 됨
Localsend를 쓰려면 한 기기에서 ad-hoc Wi‑Fi를 만들고, 다른 기기들을 거기에 연결한 다음, 그제야 Localsend를 실행해야 함
앞의 두 단계가 꽤 번거롭고, Airdrop이 그걸 알아서 처리해주니까 훨씬 마찰 없이 느껴지는 것임
최근에 쓰기 시작했는데 정말 잘 동작하고 Airdrop보다 훨씬 믿을 만했음
다만 UX는 더 좋아질 여지가 있음
그래도 Apple이 Airdrop을 좀 고쳐줬으면 좋겠음
쓸 때마다 신뢰가 너무 낮고, 기기를 못 보거나 Mac 사용자가 여러 명이면 같은 Mac을 두 번 보여주면서 어느 사용자인지도 안 알려줘서 헷갈림
그렇게까지 이런 앱이 필요할 정도로 어떤 큰 파일들을 만들고 옮기는 건지 잘 모르겠음
내 경우 휴대폰에서 생기는 파일은 사진과 영상뿐이고, Immich로 백업한 뒤 링크로 공유하면 됨
보통 사람들도 iCloud나 Google Photos로 비슷하게 할 것 같음
문서 같은 다른 파일 동기화는 ownCloud OCIS를 쓰고 있고, 대부분은 DropBox나 iCloud, 아니면 이메일이나 WhatsApp으로도 충분할 것 같음
로컬 네트워크에서 ISO 같은 걸 옮길 때는 SMB로 복사하면 되고, 사실상 어디서나 되고 별도 앱도 필요 없음
백업이라면 하드 드라이브를 그냥 꽂아도 됨
그래서 왜 이걸 써야 하는지 잘 납득이 안 감
예전엔 나도 비가시성 문제가 있었는데, 요즘은 항상 잘 되는 편임
확실하게 고치는 방법은 아직 못 찾았고, 양쪽에서 Airdrop을 껐다 켜는 게 제일 낫긴 한데 그것도 70% 정도만 통함
Sendme https://github.com/n0-computer/sendme와 AltSendme https://github.com/tonyantony300/alt-sendme를 볼 만함
둘 다 Iroh https://github.com/n0-computer/iroh를 쓰는데, 중앙 서버 없이 데이터를 보내는 오픈소스 암호화 P2P relay 서비스라서 송수신 파일 크기 제한이 사실상 없음
비슷한 스레드에서 파일 공유 앱 얘기했을 때도 이걸 추천했었음
https://news.ycombinator.com/item?id=47906587
코드가 말로 전달할 만큼 짧거나 단순하지도 않고, 그 코드를 보낼 수 있으면 보통 파일 자체도 그냥 보낼 수 있음
https://github.com/schlagmichdoch/pairdrop
비슷한 프로젝트인데, 이건 전부 브라우저에서 동작하고 "public" room을 써서 로컬 네트워크 밖의 클라이언트와도 연결할 수 있음
iPhone과 Linux 데스크톱 사이 전송용으로 Localsend를 깔아뒀는데, 항상 잘 굴러가진 않음
Firewalld에서 Localsend 포트를 열어도 기기끼리 서로 보이기까지 10분 넘게 걸릴 때가 있음
브라우저 기반이면 최소한 discovery는 더 빠를 것 같음
문서가 좀 숨어 있는데 FAQ는 https://github.com/schlagmichdoch/pairdrop/blob/master/docs/faq.md이고,
Android, iOS, Windows의 공유 메뉴 통합 방법은 https://github.com/schlagmichdoch/PairDrop/blob/master/docs/how-to.md에 있음
sharedrop과 snapdrop이 LimeWire에 인수된 뒤 망가져서 그걸 포크한 것임
Airdrop 대체제를 자처하는 것들에 대해선 spamsolutions.txt 같은 게 필요하다고 느낌
이건 기존 Wi‑Fi 네트워크에 두 피어가 모두 붙어 있지 않아야 한다는 기준을 통과하지 못함
https://craphound.com/spamsolutions.txt
비슷한 형태의 걸 Tauri로 내본 적이 있음
설치 파일 크기는 Mac 약 27MB, Linux .deb 45MB, Windows 53MB 정도였고, Electron은 바닥이 150MB쯤 됐음
.AppImage만 예외적으로 110MB 정도인데 런타임을 번들하기 때문임
이 크기 절감은 OS의 webview를 재사용해서 나오지만, 그게 동시에 비용이기도 함
Linux의 WebKitGTK는 Mac WebKit이나 Windows Edge WebView와 진짜 다르게 굴러가서, Chromium이 대신 처리해주던 걸 못 받고 크로스플랫폼 디버깅에 시간을 쓰게 됨
의외로 더 놀라웠던 건 프레임워크보다 Linux 패키징이었음
AppImage는 어디서나 돌아가지만 대부분 사용자에게는 2등 시민처럼 느껴지고, .deb는 주류 배포판을 커버하지만 계속 움직이는 glibc 버전을 따라가야 함
Snap/Flatpak은 공식적인 cross-distro 답안처럼 보이지만, 샌드박스와 권한 처리 때문에 인디 개발자는 몇 주를 태우기 쉬움
결국 .deb와 .AppImage를 배포했더니 몇 시간 안 돼서 "왜 AUR엔 없냐"는 메일이 오기 시작했음
브라우저에서도 동작함
https://web.localsend.org/
Windows에서 Android, iOS까지 전송 가능함
Firefox, Chrome, 휴대폰, 노트북으로 송수신 다 해봤음
콘솔엔
WebRTC: ICE failed, add a TURN server and see about:webrtc for more details.가 떴고, 이걸 사용자가 어떻게 해결해야 할지는 잘 모르겠더라검색해보면 대부분 개발자용 조언뿐이었음
결국 알아냈는데, Tailscale을 끄면 동작함
다만 v1.18.0이 아직 F-droid에는 안 올라옴
나도 작년에 이 영역에서 뭔가 만들고 있었음
기본적으로 peer-to-peer filesystem인 keibidrop을 만들었음: https://keibidrop.com/
지난주에 공개했고, local send가 하는 일에 더해 WAN으로도 동작함
모바일 앱은 아직 출시 안 했음
한 단계 더 나간 부분은 양방향으로 동기화되는 virtual filesystem까지 있다는 점임
저장소는 여기 있음: https://github.com/KeibiSoft/KeibiDrop
UI를 제외한 코드는 오픈소스고, loopback 기준으로 localsend와 벤치마크도 해봤는데 local send가 더 빨랐음
https://keibisoft.com/blog/keibidrop-benchmarks-vs-competition.html
어제는 /r/golang에도 댓글 스레드를 만들어보려 했음
내부적으로는 PQC, gRPC, FUSE를 사용했음
Linux로 옮긴 뒤 가장 먼저 설치한 앱들 중 하나가 이거였음
오픈소스 앱이 얼마나 좋은지 확실히 체감하게 해줬음
Tailscale이 켜져 있으면 Localsend가 지금은 안정적으로 동작하지 않는 듯함
아쉬운 부분임
같은 tailnet 안의 클라이언트끼리 파일 전송도 지원해주면 정말 좋겠음