fazo96
Public Gateway Operation
Hey @fazo96 this is very cool.
What do you need for this to work on the gateway? is it only writing objects and IPNS names?
Yes, it's just that :)
As far as working on a normal gateway, go-ipfs 0.4 already has everything. I'm waiting on js-ipfs-api to get files api support then I'm going to implement publishing stuff from the browser! (meanwhile I'm working on other parts of this app)
If you mean being able to use it from a public gateway, it's another issue entirely, because each user would need a different identity. I guess a system that lets users access an identity using an account (I mean you log in to gateway.ipfs.io via an HTTP API and you get to tinker with your own IPFS/IPNS identity with persistent ID) is possible, but it would be complex to implement. This app also needs full write access (files api + publishing to IPNS)
Of course if such an API would be available in public gateways, I would use it in this app :+1:
The other solution to having the app work without go-ipfs running on the local machine is of course js-ipfs, but I see it's gonna be a while until that's ready.
Thanks for the interest!
EDIT: I forgot to say I'm planning my own system to get multiple people to use the app via http/websockets without their own personal ipfs node, but I will start developing that later and only if there is no other solution. If when I start developing it js-ipfs is already here or close, then it won't make much sense to write it.
Still, the problem of multiple devices with one identity needs some kind of solution
and js-ipfs is not too far! :)
@diasdavid is making a "delegated" version that uses an api to do stuff and over time fill out the pieces (repo and IPNS may be all you really need to do full publishing from the browser -- @diasdavid already has the records (hard part of ipns) and @masylum just made js-repo) On Tue, Nov 17, 2015 at 10:38 Enrico Fasoli [email protected] wrote:
Yes, it's just that :)
As far as working on a normal gateway, go-ipfs 0.4 already has everything. I'm waiting on js-ipfs-api to get files api support then I'm going to implement publishing stuff from the browser! (meanwhile I'm working on other parts of this app)
If you mean being able to use it from a public gateway, it's another issue entirely, because each user would need a different identity. I guess a system that lets users access an identity using an account (I mean you log in to gateway.ipfs.io via an HTTP API and you get to tinker with your own IPFS/IPNS identity with persistent ID) is possible, but it would be complex to implement. This app also needs full write access (files api + publishing to IPNS)
Of course if such an API would be available in public gateways, I would use it in this app [image: :+1:]
The other solution to having the app work without go-ipfs running on the local machine is of course js-ipfs, but I see it's gonna be a while until that's ready.
Thanks for the interest!
— Reply to this email directly or view it on GitHub https://github.com/fazo96/ipfs-boards/issues/23#issuecomment-157464316.
I'm very excited about this :) On Wed, Nov 18, 2015 at 21:31 Juan Benet [email protected] wrote:
and js-ipfs is not too far! :)
@diasdavid is making a "delegated" version that uses an api to do stuff and over time fill out the pieces (repo and IPNS may be all you really need to do full publishing from the browser -- @diasdavid already has the records (hard part of ipns) and @masylum just made js-repo) On Tue, Nov 17, 2015 at 10:38 Enrico Fasoli [email protected] wrote:
Yes, it's just that :)
As far as working on a normal gateway, go-ipfs 0.4 already has everything. I'm waiting on js-ipfs-api to get files api support then I'm going to implement publishing stuff from the browser! (meanwhile I'm working on other parts of this app)
If you mean being able to use it from a public gateway, it's another issue entirely, because each user would need a different identity. I guess a system that lets users access an identity using an account (I mean you log in to gateway.ipfs.io via an HTTP API and you get to tinker with your own IPFS/IPNS identity with persistent ID) is possible, but it would be complex to implement. This app also needs full write access (files api + publishing to IPNS)
Of course if such an API would be available in public gateways, I would use it in this app [image: :+1:]
The other solution to having the app work without go-ipfs running on the local machine is of course js-ipfs, but I see it's gonna be a while until that's ready.
Thanks for the interest!
— Reply to this email directly or view it on GitHub https://github.com/fazo96/ipfs-boards/issues/23#issuecomment-157464316.
I share your excitement! I got an idea which is: for clients not able to run js-ipfs or to do the processing required to run the app, a server application that gathers, renders and serves everything over websockets or http. It could also provide writeable access with accounts. This would allow the app to reach a wider audience and to be used in embedded systems and internet of things devices. This backend would also help cache content from users so it doesn't get lost if no one else is online
the IPFS core (without libp2p) is very very simple, the intention is to make it run everywhere. In such cases, i would treat your backend more as a "trusted ipfs node" to delegate some operations to (or trust the routing answers from, or even run another protocol with) but still do everything on ipfs. that way the app can be truly distributed over ipfs itself. (i.e. the "stronger node" would just be a protocol in js mounted on top of that node. )
Of course, the plan for the app is already to only use ipfs for storage :)
The Backend I'm talking about is just some program on top of ipfs (with the BoardsAPI that I wrote for this app) that watches one or more boards and automatically pins user profiles of users that post in that board, thus downloading all their content and caching it. It's role is to make sure the content is always available, of course the boards would still work without this program.
It gets complicated because it also should, later down the development road, make it possible to access the app without javascript (all rendering done on the server). But I'm not sure if I'll ever do this.
hey @jbenet I have some updates about this matter :smile:
- I have been working with the files API in ipfs 0.4 and I have a ipfs0.4 branch in which I'm working on everything needed to be able to do every operation from the browser! I'm already pretty much done with everything except commenting. A problem I have with this is IPNS records being discarded after a while because they're old, but everything is backed up in mfs at the moment, so I need to implement a transparent way to get data back automatically in this case (see #83)
- I thought about making some features work with in the browser without the go-ipfs API or js-ipfs, if the app recognizes it's running from a standard read-only IPFS HTTP gateway. For example individual posts, pages and profiles could be visible. Everything that is a list will basically not work though unless there's a way to get an easily readable (like json) directory listing of an IPFS path from the gateway (maybe there is, but I don't know). Opened an issue about directory listing in json format here: https://github.com/ipfs/go-ipfs/issues/2107
This would let people at least see some content without running go-ipfs :+1: Which would be great to encourage adoption!
What do you think?
EDIT: just now saw that you'll be travelling https://github.com/ipfs/community/issues/90. Bon voyage :smile:
Implemented in https://github.com/fazo96/ipfs-boards/tree/limited-mode :smile: It was easier than expected.
I merged it in https://github.com/fazo96/ipfs-boards/tree/ipfs0.4 and when that's ready, it's gonna be in master :smile:
Next steps:
- [ ] default to
host:postof the HTTP connection in the settings - [ ] recognize limited mode when using the gateway's limited API
Paused because 0.4.0 doesn't have the read-only http api in the gateway (or I can't figure out how to enable it)