Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Public Gateway Operation #23

Open
jbenet opened this issue Nov 17, 2015 · 8 comments
Open

Public Gateway Operation #23

jbenet opened this issue Nov 17, 2015 · 8 comments
Milestone

Comments

@jbenet
Copy link

jbenet commented Nov 17, 2015

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?

@fazo96
Copy link
Owner

fazo96 commented Nov 17, 2015

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 👍

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

@jbenet
Copy link
Author

jbenet commented Nov 19, 2015

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: 👍]

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
#23 (comment).

@jbenet
Copy link
Author

jbenet commented Nov 19, 2015

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: 👍]

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
#23 (comment).

@fazo96
Copy link
Owner

fazo96 commented Nov 19, 2015

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

@jbenet
Copy link
Author

jbenet commented Nov 20, 2015

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. )

@fazo96
Copy link
Owner

fazo96 commented Nov 20, 2015

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.

@fazo96
Copy link
Owner

fazo96 commented Dec 19, 2015

hey @jbenet I have some updates about this matter 😄

  • 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 Automatically republish from mfs to make sure IPNS record stays alive #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: ability to get a directory listing in json from the gateway ipfs/kubo#2107

This would let people at least see some content without running go-ipfs 👍 Which would be great to encourage adoption!

What do you think?

EDIT: just now saw that you'll be travelling ipfs/community#90. Bon voyage 😄

@fazo96
Copy link
Owner

fazo96 commented Dec 19, 2015

Implemented in https://github.com/fazo96/ipfs-boards/tree/limited-mode 😄 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 😄

Next steps:

  • default to host:post of 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)

@fazo96 fazo96 modified the milestone: 0.1 Dec 19, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants