positive_intentions @ positive_intentions @lemmy.ml Posts 9Comments 29Joined 1 yr. ago
There's sometimes a bug where you have to have to exchange that ID both ways.
There a lot of docs to read through so just in case you overlooked it, I hope the video on this page helps: https://positive-intentions.com/docs/basics/peers
If that doesn't help, then it's something I need to fix. I am aware of a few issues with connecting to people when not on the same network. Webrtc should still work, so I chalk it up to some bug I should prioritize.
Id be interested to hear about the experience of trying to connect with the file app. I added some changes to make things work better, if that works I may have an idea of how to fix it for the chat app.
the google stuff is only for the website. the apps have their own subdomains and CSP headers that block foreign scripts.
(the direct links are found on the website footer under “links”)
the chat app is flexible in the ways it can be run as further described here: https://positive-intentions.com/blog/docker-ios-android-desktop. im trying things out with tauri and maybe some version hits the f-droid store at some point?
thanks for your reply.
can i do both? the chat app is completely open source. thats the thing i wanted to get traction on, but it doesnt seem to be working. which is understandable with things like bugs and audits missing.
so for a new approach with "file" i'm creating an app that is simplified to being purely for file transfer. i hope this simplication can also lead to more stable functionality to hopefully get to a level where it can send 300gb over webrtc. id like to this approach to remain close source so that i can create something competative in the market for file-transfer.
if youre asking for an audit, i expect you have an idea that they arent cheap. its simply beyond my means. the project is too complicated for pro-bono work.
the chat app (which contains file-transfer capabilities) is open source. id like to develop the p2p capabilities into a SaaS and so its logical to lean towards close-source for the "file" app.
thanks! im playing around with the website to make the landing page experience more appealing. the apps themselves, are running inside an iframe.
the google stuff is only for the website. the apps have their own subdomains and CSP headers that block foreign scripts.
(the direct links are found on the website footer under "links")
the web version is intended to work on all platforms without compilation.
a html file-input is simple to add on a webpage. when selecting a file, its loaded into memory. at that point you can encrypt that file and sent it over webrtc... voila; p2p encrypted file transfer.
my approach to a mobile (ios/android) version is using capacitorjs/tauri... its basically a native wrapper with a webview.
P2p encrypted file sharing is sadly still an unsolved problem
thanks for your input, but can you explain what you mean by "unsolved problem"?... p2p encrypted file transfer is demonstrated in the app.
its browser based. it uses webrtc to create p2p connections between browsers. concepts like authentication takes the form of using cryptography capabilities of a typical browser. the storage of data from messages to encryption keys are stored in indexedDB as provided by the browser of your choice. there is an emphesis on client-side browser-based capabilities in all parts of the app.
matrix is a good peer reviewed and generally reccommended solution. this project isnt intended to replace any existing solution. there are many other similar projects out there, but i notice there arent many presented as webapps. this is my attempt.
if "trust" in the static files from a url is a concern, (which is very reasonable), you can easily host your own instance.
i think it fits squarely as a "P2P app". over a hotspot, you can practically send messages offline. im not sure what other qualifiers are needed.
i dont think its ready to be compared to other tools yet. but i would be aiming to make it comparable to something like signal... but it'll take a while to get there.