Arch: File Sharing #110
Labels
No Label
android
arch
backlog
blocked-on-external
bug
bugbash
component/bindings
component/bine
component/connectivity
component/cwtch
component/tapir
component/ui
cwtch-1.14
cwtch-1.15
cwtch-beta-1.1
cwtch-beta-1.10
cwtch-beta-1.11
cwtch-beta-1.12
cwtch-beta-1.13
cwtch-beta-1.2
cwtch-beta-1.3
cwtch-beta-1.4
cwtch-beta-1.5
cwtch-beta-1.5.x
cwtch-beta-1.6
cwtch-beta-1.7
cwtch-beta-1.8
cwtch-beta-1.9
design
duplicate
enhancement
flutter
funding-needed
help wanted
hybrid-groups
in-nightly
in-progress
invalid
ios
linux
mac
need-replication-or-investigation
ops
packaging
post-stable
question
questionable
requires-more-effort-than-we-can-spare
rust
scheduled
stable-blocker
tails
testing-needed
tests
tor
waiting-on-fix-confirmation
waiting-on-new-flutter-feature
whonix
windows
wontfix
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: cwtch.im/cwtch-ui#110
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Needed to supported images / custom profiles / stickers / attachements.
High level goals (needs quantification):
Some rough ideas:
A mini-bittorrent like protcol where the top hash is published by the sender and then each block is verifiable - for p2p this would collapse to a simple file transer, for groups it would be mean they could distribute the load of hosting the file over time / offline / online
For groups we don't want to do this all in-band because otherwise the server effectively hosts the file, as such this overlay should be strictly limited to p2p.
Another option is to have the peer host a http server over Cwtch with content addressable files - this requires some amount of authentication over who can fetch the file to prevent trivial hosting attribtion attacks.
some thoughts/notes on
file download support in cwtch
Must support:
Nice to have:
Questions
Config
Misc
Design
Sending a file: should present a file picker, and then post a "download" overlay.
For rehosting, can repost download overlay from yourself (maybe with cumulative tracker/rehoster list?). Makes downloading easier for cases where original sender isnt always online.
If we support torrentiness, can rehost immediately (before dl is complete)
file "ticket" overlays
download protocol
chunk request format
notes off the top of my head:
consent: partly related to DoS prevention, but in general, file is for 1-n ppl to download only, only those approve (contact or group).
Q: how does that interact with rehosting wrt groups.
to some extent yeah once we send someone a file they can do with it whatever they want... (but at least hte ui doesnt have to support that easily)
we probably want some logic if we're doing bittorrent like downloading, like again, a) whats a sane default for chunk size, followed by what # chunks or file size do we stick to downloading from host and at what point are we more likely to enquire with group memebers
also if the orig host is offline and it's a group context then yeah depending on size threshold just pick one at random or grab from multiple
"file servers" under nice to have, again this may need some relational thought to group contracts and how "open" something is vs how restricted.
pre-dl thumbnails? - we can prolly get some basic image file type images from marcia for like doc, image, audio etc to start with ^_^
Thinking more about this today in regards to implementation (do not take anything here as design gospel this is mostly for my own reference):
It would be nice to be torrent-compatible, but most torrent libraries are heavily embedded into the http/ip dynamic and we have no hope of disetangling that enough (and I'm not comfortable embedding such a library in Cwtch)
Really there are 2 main usecase here and they are pretty distinct:
Everyone needs to be able to download (1) in order to participate in the conversation and so chunking and distributing makes very little sense in that case (in theory at least) . The file is likely small enough to be downloaded via a single connection and that connection is likely to remain online during the conversation.
(2) lends itself more to the torrent approach, kinda falls down when it comes to practicality i.e. one person in a group hosting a file server is almost certainly more efficient although not the most robust.
Makes me want to revisit a bot-orented group design where we always assume a bot is online for management and authorization. Even if the bot only acted as a "tracker" to allow people to efficiently find chunks (rather than host the file itself) it would greatly improve the efficiency and discoverability and we could probably layer it onto the current design in a graceful way.