Peergos
Peergos copied to clipboard
Peergos
[Question] Addons
Is there a way to provide custom Add-ons for the WebApp that use Peergos for data storage? For example webmail client.
We have already implemented an email bridge if that's what you're looking for (not publicised yet, but you can see https://github.com/Peergos/email-bridge/ for the server side, and add ?email=true to the web-ui when logging in). The bridge connects to a standard smtp account and downloads emails, encrypts them, and stores them in your peergos space. It also looks for new outgoing email files in Peergos and sends them as real emails. The bridge is designed to not expose previously received or sent emails if it is hacked. We'll be writing a blog post on this soon.
More generally, we plan on implementing a browser sandbox mechanism that allows anyone to implement an app using HTML5 that is itself served from a directory in Peergos. Then allow users to grant such an app various capabilities.
The mail bridge looks awesome! Now I'm just missing a password manager.
Do you have any idea when this sandboxing will be usable? I would be interested in trying it out. If this works sky is the limit.
Glad you like it! :-)
A password manager would be a great app. At moment the best you can do is store them in a text file in Peergos. But a custom app with search, **** hiding etc. would be much better.
We've applied for a grant to fully implement the sandbox, but we're waiting to hear back.
Ahh I see. Whats your estimate, on how much effort implementation will take?
If you need help with conception or implementation I would gladly donate some time.
That's very kind! We have it mostly specced out and designed, and hopefully should hear back any day now. There are a few things we need to get done first though, like the mirror capabilities described here https://twitter.com/Peergos/status/1460917685269798918
By far the most useful thing for us would be to encourage friends to sign up and upgrade to paid accounts. That's how we can make this sustainable and keep working on it without relying on grants which are a bit of a lottery.
Do you offer bigger then 50GB? I would need 300GB to switch from my current Cloud Based solution
We did not get the grant - it's always a bit of a lottery. So it will take some more time.
We've published some docs on the application sandbox here: https://book.peergos.org/features/apps.html https://book.peergos.org/features/private-web.html We're hoping to merge it soon.
This is awesome! Is there away to access friend list or exchange data with a friend. I'm thinking multiplayer boardgame. Can this be achieved when sharing a folder and get access for that folder? So App writes a file to a folder that user A and B have access to and user B then reads that data from the app. Maybe the folder sharing can be done from within a app? But I don't want to be too gready.
It's not merged or deployed yet, we just wanted to give you a heads up. It's basically good to go, except the new headers are blocking our own payment page...
The permissions are quite simple to begin with, but we plan to add more. We'll need to consider the possibilities and privacy/security implications, and would love your input. Multiplayer p2p games are definitely in scope.
I understand its not merged yet. Once it's merged, I'll give it a try a begin with an easy app. That will give me a better understanding for if there is anything holding back it's potential.
Just of the top of my head it might be useful if an app could "watch" a folder an gets notified on changes.
And another important functionality would be if an app could share it's internal folders with other users.
I have added a few sample Apps here: https://github.com/Peergos/example-apps
This is now merged and live on peergos.net! We'd love to hear what you think after trying it out.
Okay I hab a bit of time to look into it.
So there a few questions that came up.
-
Why didn't you make it possible to edit files in a folder. What's the reasoning behind the decision to also only allow a app edit a file.
-
So what's the plan for the mobile UI? I get the idea to just use a pinned website. But a mobile app usually brings a bit more then a website.
- Offline persistent
- Biometric unlook
- Notifications (media player start/stop) (This might deserve a new issue)
-
Is there any Idea for websockets or some way of communicating in Realtime with peers. IPFS pubsub would be awesome.
-
Someway to share app data files with other users would be great.
And one more thing do you have something to mock the backend or some faster way for developing.
It might be useful to allow for a dev mode in the peergos instance. The devmode should set the subdomain of the app to something static that I can run a local webserver on. That way I could use React Hot reload.
Little sidenote - how are the Subdomains working locally?
These are good questions.
- We wanted to understand the use cases better first. What did you have in mind?
- We'd love a mobile app, but we don't have the resources to build and support it at the moment. We'd also like to see how far we can get with just a PWA. I think we should be able to do all those things in a PWA.
- We'd love to have a permission that can open a p2p stream to another person running an app. We already do this extensively on the server side, but it will require some engineering to be able to expose that in the client.
- This is relatively easy and we should be able to add a permission/API call for that.
What is slow about developing? Is it the fact you have to reinstall each time? Some apps you can just edit in place and re-launch (depending on the permissions), but we could let you browse directly to the app's install folder and then you could do that for any app. Would that help? Or alternatively we could let you launch any app from its dev folder without installing?
The subdomains work even better locally, because you don't need TLS certs for localhost.
- Also not sure, just thought it was odd. If I can think of a usecase i'll let you know.
- I have some experience in flutter, react-native and ionic development. Even I don't like Ionic that much, it would probably be the best fit, since it would allow you to basicly just run your current web-ui and it allow access to hardware APIs. But my personal favorite would be a Flutter App with Javascript interop. That would give you the most native app without having to maintain sooo much extra code. But you would need to find a way to intergrate the new apps which need to be loaded in a seperate webview. Maybe something to explore if there is some sparetime. But even if you being able to get it to run peergos.org would need to sign up for a Apple Developer Account to deploy your App. And Apple has some limitations on whats allowed in the App-Store that might prevent you from offering a iOS App. Thats way a PWA would be the easiest, even if I don't think a PWA feels super native.
- Streams would be awesome. It might be useful to abstract streams a bit further into "rooms". Rooms are more useful then simple streams since they can give you user context as well as avalibility. (https://www.npmjs.com/package/@daishi/ipfs-pubsub-room). Room could be treated as "folder" of streams maybe some of the mechnics for sharing folders can be useful here.
Well developing is slow, because currently. If I develop in React I'll need to compile, deploy, install and relaunch. What ever can be done to eliminate any of the steps is useful. But what I was talking about is the following.
Host a dev webserver on localhost:3000. And being able to launch a App thats loads localhost:3000 instead of is usale subdomain. That way I should be able to just use the react hot reload and "skip" als manual steps that would greatly increase the development process. I aware that shouldn't work agains peergos.net but thats fine. Just allow this again a local instance. Maybe provide a "Dev App" that I can be pointed to another domain.
I assume the webview can handle iframes? If it can do so for localhost domains then it might work as is in Flutter?
That's a good point about the app stores, ideally we'd like to avoid depending on big tech to let people install peergos.
If you want async broadcast to a group then we could just add an api for accessing the chat protocol.
You're right that a tight dev loop is important. I'll have a think what we can do. If your build process is in JS, then you might be able to run the react build process itself as an app in peergos.
I assume the webview can handle iframes? If it can do so for localhost domains then it might work as is in Flutter?
Yes that would work. Not to sure about the localhost domains but that would be something to tryout. The Problem is that for offline functionälity to work you would need a peergos instance on the device that should work on android but what about ios?
How much of the code is Java code can be transpiled to javascript? Can the server run on nodejs?
That's a good point about the app stores, ideally we'd like to avoid depending on big tech to let people install peergos.
I also wouldn't want that, but for wider adoption it will need to be easy to use. That no Problem for Windows, Linux, Mac and Android. But for now sideloading on iOS doesn't work. Maybe that changes at some point when EU forces them to.
You're right that a tight dev loop is important. I'll have a think what we can do. If your build process is in JS, then you might be able to run the react build process itself as an app in peergos.
I just tried a hosts file override for the subdomain to localhost that works, but what do i need to present that peergos accepts the subdomain as an app?
The server side only code (package peergos.server) is not (and won't) compile to JS. In principle we should be able to build native iOS binaries from Java using GraalVM, e.g. https://gluonhq.com/java-on-ios-for-real/
The app architecture looks like this.
The server serves up the same static assets for all sub domains (the files in web-ui/assets/apps/sandbox/)
The SW created by the code communicates with the main peergos tab to retrieve the assets for the app. So the server never sees any app assets, or even the app's path.
So in principle you could fork those sandbox assets to not retrieve app assets from peergos but maybe directly from the fake subdomain server? Then you would be bypassing peergos entirely just for the app assets, but the api calls would work as is.
If we can create iOS Native binaries a Flutter App would be awesome.
I'm soon on vacation, i'll get an offline version of the tech book and try to get a better understanding how the communication is working. But having the server on device would be awesome and something thats likely not possible with a pwa. That would make true p2p possible.
I'll checkout the sandbox assets and see if I can get a dev enviroment going. If that works we could maybe change something in peergos that the dns override is not nessary on localhost.
Yep, we're also trying to hold off on putting server's on everyone's device until we can build in anonymity protection into libp2p. Otherwise the risks are too high, and most people won't understand that it's broadcasting their IP with unforgeable signatures (the ipfs node id) as well as making their friend graph easy to deduce.
We can probably put a flag in the service worker to check if domain is localhost and ?insecure=true is in the URL, and then send app asset requests directly to the subdomain, and add a daemon arg to proxy subdomain calls to some other localhost server? What do you think @kevodwyer ?
Yep, we're also trying to hold off on putting server's on everyone's device until we can build in anonymity protection into libp2p. Otherwise the risks are too high, and most people won't understand that it's broadcasting their IP with unforgeable signatures (the ipfs node id) as well as making their friend graph easy to deduce.
That makes sense, but for true offline-first p2p, the server shouldn't exists or atleast be present everywhere. So maybe doing a viability study for the app might be useful, but for actual development and deployment libp2p should increse its privacy first. Should we open a new Issue regarding the app or just take it to matix?
We can easily get read-only offline by just caching what you want access to. We could also allow a "work offline" mode when all writes are cached until you can commit later. This would cover most offline use-cases I think. There's a lot of work to do before client-side p2p is safe.
What do you mean by a viability study for the app?
We can easily get read-only offline by just caching what you want access to. We could also allow a "work offline" mode when all writes are cached until you can commit later. This would cover most offline use-cases I think. There's a lot of work to do before client-side p2p is safe.
One thing that won't work, is interacting with peers "offline"
What do you mean by a viability study for the app?
We will need to see if the cross compiling works well enough. And then eveluate how much code is duplicated. If we don't do true p2p we might be better of with a pwa. I think flutter would only make sense if we plan to do something, in the future, thats not possible with a pwa. Because we will need to translate the whole vue.js application to flutter.
One possibility to enable interacting with peers offline is to use local transports like bluetooth or mdns. If that's combined with document types that are CRDTs then you can get full functionality within those docs.
I definitely want true client-side p2p on mobile eventually, I just know it's a lot of work. Another unknown is how to integrate the go code for ipfs-nucleus on mobile.
One possibility to enable interacting with peers offline is to use local transports like bluetooth or mdns. If that's combined with document types that are CRDTs then you can get full functionality within those docs.
Local Transport would be needed anyway. And are CRDTs not something that you will need implement per Apps? Functionality like sharing a file locally (basic opperation) wouldn't need CRDTs. Apps like Calender might be able to use CRDTs. But i'll need to get a better understanding how interaction between client and server works. In general I'm usally a fan to keep
I definitely want true client-side p2p on mobile eventually, I just know it's a lot of work. Another unknown is how to integrate the go code for ipfs-nucleus on mobile.
go-mobile might be a solution to get ipfs-nucleus working with flutter. This is something that needs to be evaluated. If a "real" mobile app is something thats acctually wanted. You should maybe create a new Repo where we could collect some Issues that will need to be evaluated.