That sounds cool π If you do decide to make it FOSS I'd be happy to try it out and give feedback.
this post was submitted on 26 Apr 2025
148 points (84.3% liked)
Privacy
37971 readers
333 users here now
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn't great, if contents of the website are behind a paywall maybe copy them into the post
- Don't promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
much thanks to @gary_host_laptop for the logo design :)
founded 5 years ago
MODERATORS
Thanks!
Perhaps you'd like to give feedback on a separate but similar foss project: https://github.com/positive-intentions/chat
That looks cool - thanks for the link :)
this app is not libre software.
useless
Foss or gtfo. Im not letting a black box see my files. I dont care what you claim, I have been burned before.
load more comments
(6 replies)
There ain't no trust in this game. If it isn't open source then it's pretty much dead in the water. You can't compete with OSS with closed code in this space, really. There's a few alternatives (and ones that are more mature and proven) that will always be first choices.
Absolutely. Also, it probably is in your best interest to advertise details of your cryptography. What data is shared with whom, what algorithms are used, etc.; if you're doing something more exotic / low-level, Alice-Bob diagrams can be helpful. I'm not sure what other people do but when looking at security-sensitive software, the first thing I do is look for the cryptographic setup and research it.
I'm in the process of rebranding and moving domains, so the documentation links are broken. You can try the search. it seems to work reasonably well. A good place to start could be from here:
https://positive-intentions.com/docs/research/authentication#authentication-sequence
Feel free to reach out for clarity on anything.
Thanks.
I have a similar open source project. https://github.com/positive-intentions/chat
My general thoughts are that it isn't sustainable. While it clearly isn't a contender in the messaging-apps market, I think it demonstrates a unique concept in how it works as a webapp.
So it's like croc, but closed source?
I have a weird setup with open and closed source.
I have open source examples of this code in action. If interested: https://github.com/positive-intentions/chat
I understand you want to make money from this, but for privately sending files, the much more mature and free open source projects will be greatly preferred. So I dont see this app going anywhere. Closed source doesn't lend itself to privacy all that well. Gl.
strong title
- not open source
- similar to other free software but might have some difference (webrtc?)
- what is the market for that target user (doesnt seem include lemmy audience) who needs that difference
load more comments
(10 replies)
Cool project, but it seems to be very similar to PairDrop with the major downside of not being open-source. What would be the advantages of using this project over existing FOSS-solutions?
load more comments
(1 replies)
If it's not open source then forget about it, it won't go anywhere. I've had that stance of all software for decades now, but in the last few years boat loads of others have caught on.
Its simple really. If the software is open source (ALL of it, servers, clients) we can all check it and all be sure it does what is advertised. If not, we have no way of knowing what you're doing, especially on the server side of things, and if we've finally collectively learned on thing, it's that we can't trust companies on the server side of things. Data WILL be used in other ways than advertised.
Since this software is supposed to be a security product, trust is paramount, and it's bot there at all. Unless this product would be open source I won't even look at it.
load more comments
(3 replies)
How is this different than FTP?
This is using the WebRTC protocol. As a webapp it's immediately good to go, there isn't a need to run something like a FTP server.
Of course limitations apply like sending larger files nukes my ram... But I after it's sent, it seems to settle down.
From Switzerland, Sharrr, OpenSource, encrypted EE2E, no knowledge, 10GB/file, one time download. From the same author, https://scrt.link/, for share autodestructive encrypted notes.
Nice! Can you tell me more about zero-knowledge encryption?
In my app I'm using asymmetric encryption to exchange a symmetric encryption key (Diffie-helman). I'm curious about other approaches for P2P authentication.
it means exactly this, the server hasn't any knowledge about your uploaded files or encrytion key. It's very save, but not really P2P, because of an server in the middle where the files are stored until download. Real P2P is eg, Croc, which transfer files direct from one PC to the other, without any server in the middle, you send an link which pointed direct to the files in your PC. The advantage is that you have anytime full control over the files and with this no limits on filesizes, but maybe a drawback is, that downloads are only possible, when your PC is online, on the other hand, this permits also to interrupt downloads, simply going offline, (it's FOSS)
Closed source and a crowded market.
Sorry to say, but I don't think you understand the audience for this.
If interested in how it works and to see code examples, this project is based on my beefier open-source code seen here: https://github.com/positive-intentions/chat
load more comments
(2 replies)
load more comments
(1 replies)
I use magic wormhole for these sorts of things. There are many FOSS clients and the protocol is open. Here's my android client of choice and my Linux client of choice. There are also many options of other GUI and command line implementations.
By the way this is a maintaned fork of your Android Client: https://github.com/iyox-studios/iyox-Wormhole
Thanks. I hope to get to a point where I can make the experience as seamless as workhole.
To compare solutions, a key details around providing my app as a webapp, is to avoid the requirement of a client. this opens up the set of compatible platforms.
(Note: it's a common request for me, so by popular demand, i will aim to provide binaries for the major platforms.)
I need this. But ffsend + encrypted zip file works most of the time. Or onionshare.
Not sure I see how this helps.
For me, it's an achievement for it to be comparable to those tools. I aim to get to a similar feature set and make the user experience intuitive.
I'm of the opinion that you should probably provide Source Code on a "Source Available" basis to people who ask and have a need to see it to audit or self-compile. The lack of "Open-ness" in your code is disturbing.
I won't comment or judge on your decision to refuse to offer this software on a Libre basis. You absolutely have the right to monetize as necessary; especially if this code is speaking to a backend infrastructure that you maintain for it. Even if all you do is aim to break even and pay for those servers.
The experience is extremely unintuitive. I couldn't get your app to work at all on my privacy enforcing browser within the confines of my privacy enforcing LAN. (Yes; I do/did enable WebRTC and the other required technologies, however they're enabled in a privacy respecting manner.) Neither of my devices would show or remain connected once added. There were no popups or information given to me by the app to troubleshoot the issue; and I'm not going to crank open a Dev Console for something that I can't contribute to anyways. If your software is going to remain closed in source; "It should just workβ’".
thanks!
im a developer im not much of an expert on licences of any kind. i created code and decided to open source it here: https://github.com/positive-intentions/chat . when i say the close source app is "based on" the open source code, i hope it doesnt undermine that it itself is a fully functional p2p messaging system (im of the opinion that all projects will always need refinement). anyone with issues about close-source code should take a look at the open-srouce version. its basically more functional but it seems too complex to maintain as open source andd thus this new project.
id like to offer the statics as a zipped folder. this is in the roadmap, but the code will be minified and obfuscated. about as opaque as possible for "source available". i dont know much on the matter, but id like to learn more about if this can be made into libre software. its hardly modifyable or studyable.
while i dont want you to "trust me bro", i am actively developing it and improving the functionality. so that static bundle will have to be build by the CI/CD and it will update along with the app. it goes without saying, the project is not mature enough to have things like security audits.
thanks! for your feedback there! ahh the connection bugs. unfortunately this is is one of the trickier bugs. im working towards fixing that asap. i have an idea of a fix, but im trying to avoid rewriting a core piece. have you tried closing the app on both devices and trying again (sorry, i know its a bit cliche).
if its not a secret, can you maybe tell me more about your LAN setup for me to set something up and try? i certainly aim for it to "just work".
Obfuscated code is not "Source Available". You will need to provide the code without obfuscation; though I don't personally blame you if you're choosy about what reasons you will release the source for.
Network is standard double NAT grade B. [ISP <-> Router <-> Firewall <-> Client] with all necessary port forwards in place (TCP/UDP 1025-65535 to Firewall). Firewall is standard pfSense CE; and will forward invisibly and does automatically perform necessary UPnP and port forwarding as detected. STUN may be necessary but does function and establish the route(s) and the ports your application selected would ordinarily be invisibly NAT'ed quickly by the firewall as long as the packets are solicited.
ICE Candidates udp <Public IPv4>:65359 srflx udp <Public IPv6>:65363 srflx udp [<Public IPv6 /64 issued by ISP>]:54597 srflx udp [<Public IPv6 /64 issued by ISP>]:58798 srflx Error: No active TCP candidates were found
To my knowledge your application does not appear to opinion or declare if it uses STUN. (Perhaps it should, there are valid reasons to offer STUN or not offer STUN). The application provides no meaningful errors so I can't tell what might need adjusted or allowed network-wise.
Very cool this is similar to dibbles. How is it different?
I haven't heard of Dibbles. Can you point me to their site?
I'm sorry I lied. I made it up. I just wanted to fit in with everyone else shitting on the person creating stuff.
Bruh
view more: next βΊ