web version

[shama]

Tracking what's need for a web version:

• brfs is having issues with protocol-buffer
• ghsign relies on the filesystem and uses request which isn't web compat
• Make calls to leveldb go up and use level.js in web.js
• swarm.js shouldn't rely on the file system

[Flet]

Had a good time tonight playing with this :)
http://flet.github.io/friends/

code is at https://github.com/Flet/friends/tree/web

• ghsign and github-current-user are disabled since they use the filesystem
• ./lib/db.js created and checks process.browser to determine if it should use level-js
• the only filesystem dep in swarm.js is its use of ghsign (and helper func which uses request)
• I had to add -t brfs to the beefy call to get it to work... maybe that solved the protocol-buffer item above

I think the ghsign stuff could totally be pulled out of swarm.js in a similar way that db.js was done in this hack.

@beaugunderson I ran into this error coming back from your signalhub... may need some CORS headers:

EventSource cannot load https://beaugunderson.com/signalhub/v1/friends-friends/ci9f8zl7600003653nyojtrnf.
No 'Access-Control-Allow-Origin' header is present on the requested resource. 
Origin 'http://localhost:8080' is therefore not allowed access. The response had HTTP status code 502.

[shama]

Wow @Flet! Nice work! :D

[Flet]

Wow its working through the Evil Corporate Proxy too heh 👍

[Flet]

@maxogden is it possible to add CORS header to signalhub.publicbits.org?

GET https://signalhub.publicbits.org/v1/friends-friends/all 
(index):1 EventSource cannot load https://signalhub.publicbits.org/v1/friends-friends/all. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://127.0.0.1:9966' is therefore not allowed access. The response had HTTP status code 502.

[kumavis]

Interested in contributing -- let me know where we are at after flet's work and what piece I could bite off
still familiarizing myself with the codebase

[Flet]

Excellent! :)

I think #129 and also moving swarm to its own module tick a few of @shama's boxes above.

brfs is having issues with protocol-buffer

• not exactly sure on this one..? I think this was a non issue in my web branch.

ghsign relies on the filesystem and uses request which isn't web compat

• with Separate sign and verify from swarm.js #129 sign/verify is abstracted out of swarm.js, which allows for the web version to provide its own web compatible sign/verify functions. But still need to figure out how to sign/verify in a browser friendly way (sigining with a private key is going to be a good puzzle).

Make calls to leveldb go up and use level.js in web.js

• whats cool is swarm.js just tags a reference to a levelup-compatible interface. In my web branch I switched the underlying implementation to level.js and things worked pretty well.

swarm.js relies on the file system

• with sign/verify abstracted away and with something like level.js for a db, we should be able to avoid reliance on filesystem. The schema.proto is read from the filesystem, but browserify handled this swimmingly in my web branch.

[max-mapper]

@Flet i just added more cors headers to signalhub https://github.com/maxogden/dat/blob/master/lib/rest-server.js#L9-L14 and upgraded it on my server, lemme know if it works now

[shama]

brfs is having issues with protocol-buffer

Doesn't appear to be an issue anymore for me either.

[Flet]

@maxogden cool, its looking good now!

[Flet]

ah, @maxogden I may have spoken too soon... I get a 502 from nginx when hitting https://signalhub.publicbits.org/ (instead of the name/version json).

[max-mapper]

oops my bad, apparently I didn't have it set to start on reboot

On Sat, May 23, 2015 at 1:23 PM, Dan Flettre [email protected]
wrote:

ah, @maxogden https://github.com/maxogden I may have spoken too soon...
I get a 502 from nginx when hitting https://signalhub.publicbits.org/
(instead of the name/version json).

—
Reply to this email directly or view it on GitHub
#112 (comment).

[feross]

I just pushed a bunch of changes to make it work in the browser. Thanks @Flet - your code was really handy for that.

[Flet]

Cool! But also simple-get does not support web proxies on the node side of things, so that could break the app for some folks.

I really hate the proxy situation in node.js... I wish it could be handled by node itself :(

[feross]

@Flet Could you elaborate? I don't understand the web proxy issue.

[Flet]

Sure! The request package respects the http_proxy and https_proxy environment variables and sends requests through the specified proxy (using tunnel-agent I believe).

In the browsers this really is not an issue as all browser allow proxies to be configured. For node however, core does not do any proxying. Related node issue nodejs/node#1490 -- doing something like node -r write_your_own_proxifier index.js is interesting, but I don't know of any implemented package that does this. Also it does not necessarily fit with the npm start paradigm.... but I digress.

Some of sindresorhus' packages use his cool little got package, but there isn't web proxy support, so a lot of node-targeted tools that use it will not work in a locked down corporate environment.
Related got issue sindresorhus/got#79 (kevva's caw package looks to be the solution, which also uses tunnel-agent).

[Flet]

For friends, ideally if we have a web version running, users behind a proxy could use the web version and be fine. 😅