Ask HN: How can self hosted apps(browser) converse with no central medium?
12 comments
A few ideas from a quick brainstorm, none of them are perfect, but neither is the centralized server solution:
1. Bookmarklet - In a similar vein to the way some password managers work you could construct a bookmarklet that the user can click on to make a site do the right thing - there are some security configurations depending on your threat model - however this does require user interaction.
2. Browser plugin - like #1 but obviously with the pain of writing and maintaining a browser plugin.
3. Bake the site determination into the flow - so instead of a 1-click retweet it becomes a 2-click retweet with the second step requiring the user to provide the site where they want to retweet - again some security implications and breaks the regular flow (although you could get around this by doing it once and storing the value in a cookie)
4. Have a local app listening on a specified port (so retweets get POSTed to 127.0.0.1:7000 for example) and then from there onwards - requires extra setup, makes the system less portable (can't just throw it on a hosted server). Like #2 but more annoying.
1. Bookmarklet - In a similar vein to the way some password managers work you could construct a bookmarklet that the user can click on to make a site do the right thing - there are some security configurations depending on your threat model - however this does require user interaction.
2. Browser plugin - like #1 but obviously with the pain of writing and maintaining a browser plugin.
3. Bake the site determination into the flow - so instead of a 1-click retweet it becomes a 2-click retweet with the second step requiring the user to provide the site where they want to retweet - again some security implications and breaks the regular flow (although you could get around this by doing it once and storing the value in a cookie)
4. Have a local app listening on a specified port (so retweets get POSTed to 127.0.0.1:7000 for example) and then from there onwards - requires extra setup, makes the system less portable (can't just throw it on a hosted server). Like #2 but more annoying.
Number 3 is pretty good honestly. It might be the best option in fact.
Make persona.com an oAuth provider. Force person a to authenticate with persona.com when they click the reshare button. Once authentication is done, personb.com knows that it has to talk to persona.com. Then call the reshare API on persona.com.
This will be a multistep process for the first reshare, but once person a is logged into persona.com and has granted access to personb.com then should be a seamless single click experience.
This provides the added benefit that only person a can reshar on persona.com.
This will be a multistep process for the first reshare, but once person a is logged into persona.com and has granted access to personb.com then should be a seamless single click experience.
This provides the added benefit that only person a can reshar on persona.com.
I was thinking of this. It's not a great experience, but it might be the only pure browser based options that will work. Along those lines I thought:
Person A clicks reshare. Gets asked for url. Person A types in persona.com. Immediately a window pops up which is persona.com/reshare?s=personb&id=4 or something along those lines. This is similar to what happens if you click retweet or fav on an embedded tweet right now. I'm actually ok with this workflow even if it's clunky (you have to click reshare twice to do a reshare). I just wish there was a better way to tell personb.com to automatically recognise that persona.com is associated with resharing.
Person A clicks reshare. Gets asked for url. Person A types in persona.com. Immediately a window pops up which is persona.com/reshare?s=personb&id=4 or something along those lines. This is similar to what happens if you click retweet or fav on an embedded tweet right now. I'm actually ok with this workflow even if it's clunky (you have to click reshare twice to do a reshare). I just wish there was a better way to tell personb.com to automatically recognise that persona.com is associated with resharing.
Make the usernames "[email protected]".
If the user is already logged in the button will act normally. If its not you simply ask them to log in. If they use [email protected] on personb.com, handle that in the login code and start the regular OpenID flow with persona.com to authenticate. personb.com is now allowed, on behalf of the user, to reshare this content on persona.com, and sends the data directly to an endpoint there.
If the user is already logged in the button will act normally. If its not you simply ask them to log in. If they use [email protected] on personb.com, handle that in the login code and start the regular OpenID flow with persona.com to authenticate. personb.com is now allowed, on behalf of the user, to reshare this content on persona.com, and sends the data directly to an endpoint there.
Can you just have person A supply to personb.com the path to person A's sharing service (in this case persona.com) and craft share links to person A's sharing service pointing to the content from personb.com you want to share?
Let's say:
Share endpoint /share?content=URL
Content endpoint /content/ID
If personb.com knows that the client shares from persona.com/share, it can craft its share links as (excuse the escaping)
This seems to address your core use case as well as your stated kicker (you can't craft a request to get person A to reshare something they don't want to since persona.com/share can auth person A and confirm the share).
This is all essential how Facebook, G+, Twitter sharing all work, except you don't pass to your content site the share endpoint because it uses canonical endpoints built in.
Let's say:
Share endpoint /share?content=URL
Content endpoint /content/ID
If personb.com knows that the client shares from persona.com/share, it can craft its share links as (excuse the escaping)
<a href="https://persona.com/share?content=http://personb.com/content/5</a>
This seems to address your core use case as well as your stated kicker (you can't craft a request to get person A to reshare something they don't want to since persona.com/share can auth person A and confirm the share).
This is all essential how Facebook, G+, Twitter sharing all work, except you don't pass to your content site the share endpoint because it uses canonical endpoints built in.
This would be the ideal workflow because it's non platform dependent (works on desktop and mobile browsers with no additional steps). The question is, how does the browser tell personb.com that the reshare point for the current visitor (person A) is persona.com.
Struggled with this since there doesn't seem to be a way for the browser to set a value that's writable by one site but readable by any site
Struggled with this since there doesn't seem to be a way for the browser to set a value that's writable by one site but readable by any site
I don't think you can make something like this fully distributed with current web technologies, but one solution would be to use a centralised domain for identification.
When Person A signs up / logs in their instance includes an iframe at personident.com which sets a cookie saying their instance is persona.com.
When they visit Person B's site the include an iframe for the share endpoint at personident.com. That knows about persona.com, so displays a button to share to their instance.
Iframes may sound nasty but this is how all the social sharing buttons work at the moment. I think the code on personident.com could just be JavaScript, so hosting would be easy.
When Person A signs up / logs in their instance includes an iframe at personident.com which sets a cookie saying their instance is persona.com.
When they visit Person B's site the include an iframe for the share endpoint at personident.com. That knows about persona.com, so displays a button to share to their instance.
Iframes may sound nasty but this is how all the social sharing buttons work at the moment. I think the code on personident.com could just be JavaScript, so hosting would be easy.
It sounds like you are implementing a distributed social network. https://en.wikipedia.org/wiki/Distributed_social_network
There are quite a number of open source projects trying to solve similar sounding problems. Perhaps you could look at these projects for inspiration? https://en.wikipedia.org/wiki/Comparison_of_software_and_pro...
Many of the projects are purely "protocol" projects, which you may be able to leverage to achieve what you want without having to implement it yourself.
There are quite a number of open source projects trying to solve similar sounding problems. Perhaps you could look at these projects for inspiration? https://en.wikipedia.org/wiki/Comparison_of_software_and_pro...
Many of the projects are purely "protocol" projects, which you may be able to leverage to achieve what you want without having to implement it yourself.
It seems like you are working towards a "everyone put their social stuff on their own site" model, which really lines up with the indiewebcamp ideal. I would recommend looking at https://indiewebcamp.com/webactions, as it's almost exactly what you are looking for, and requires little to no browser support at all, just the ability to register a url as a handler for a protocol. Biggest issue is just getting all the different sites to have support for webactions. The other bit you need is https://indiewebcamp.com/indie-config
You need to maintain state related to which is user's own version of website and which is not.
This state needs to be accessible to all versions of your apps.
As far as my knowledge goes, it is not possible without a central medium. You can either maintain it in a remote server or in a master_domain cookie, to which all apps can redirect, to read current state(similar to SSO).
The second approach is not that clean and you would still need a central server, I would prefer first approach only.
Sharing states/cookies across domains is not supported by browsers due to security concerns. So doing it completely in browser is not possible at moment.
This state needs to be accessible to all versions of your apps.
As far as my knowledge goes, it is not possible without a central medium. You can either maintain it in a remote server or in a master_domain cookie, to which all apps can redirect, to read current state(similar to SSO).
The second approach is not that clean and you would still need a central server, I would prefer first approach only.
Sharing states/cookies across domains is not supported by browsers due to security concerns. So doing it completely in browser is not possible at moment.
If your network is to be used by technically more savvy people you could use this approach:
On personA site there would be a field which accepts a 'reshare' code when the user is logged in.
Clicking on the reshare button on personB site would (by default) display a reshare code. This code would contain information such as personB URL, id of the post etc.
Pasting the reshare code into personA site would result in a (backend) communication between personA and personB sites to sort stuff out.
When using reshare function for the first time on personB site, the site would propose to enter the URL of 'your own' server in order to transform the reshare button functionality.
Once personB site knows the url of personA, it would transform the reshare button so it actually constructs an URL in the means of personA/reshare/from/personB/reshare-code.
Since the user is presumably logged in (with cookie/local-storage token) to personA, this would redirect him to personA, the backend of personA would eat the reshare-code and could offer a dialog asking for confirmation of a reshare. Once validated it could ping personB site that the resharing was complete.
On personA site there would be a field which accepts a 'reshare' code when the user is logged in.
Clicking on the reshare button on personB site would (by default) display a reshare code. This code would contain information such as personB URL, id of the post etc.
Pasting the reshare code into personA site would result in a (backend) communication between personA and personB sites to sort stuff out.
When using reshare function for the first time on personB site, the site would propose to enter the URL of 'your own' server in order to transform the reshare button functionality.
Once personB site knows the url of personA, it would transform the reshare button so it actually constructs an URL in the means of personA/reshare/from/personB/reshare-code.
Since the user is presumably logged in (with cookie/local-storage token) to personA, this would redirect him to personA, the backend of personA would eat the reshare-code and could offer a dialog asking for confirmation of a reshare. Once validated it could ping personB site that the resharing was complete.
Due to the 2000 character limit I couldn't add the following:
I'm sorry if this comes across as a question that belongs on Stack Exchange. It's a genuine problem that I've been putting off for the last two years, and I finally need to address it. IRC's and other resources have all eventually pointed me in the direction of central servers. I even tried using custom url prefixes like "reshare://" but the experience is terrible since any site can attempt to set the protocol handler for reshare://. Imagine browsing to a random site (like a torrent seeder) that tries to hijack the reshare:// protocol. So currently stuck. Would appreciate any feedback and thoughts on this.
Thanks :)
I'm sorry if this comes across as a question that belongs on Stack Exchange. It's a genuine problem that I've been putting off for the last two years, and I finally need to address it. IRC's and other resources have all eventually pointed me in the direction of central servers. I even tried using custom url prefixes like "reshare://" but the experience is terrible since any site can attempt to set the protocol handler for reshare://. Imagine browsing to a random site (like a torrent seeder) that tries to hijack the reshare:// protocol. So currently stuck. Would appreciate any feedback and thoughts on this.
Thanks :)
I don't think you should be so quick to dismiss custom protocol handlers. To me that's the correct way to do this. Browsers are responsible for not letting handlers be hijacked. It's already used widely for mailto links. Firefox: https://developer.mozilla.org/en-US/docs/Web-based_protocol_... ; Chrome (needs web+ prefix): https://developers.google.com/web/updates/2011/06/Registerin...
There is cross-domain local storage but it involves a central server and iframes, https://github.com/zendesk/cross-storage
There is cross-domain local storage but it involves a central server and iframes, https://github.com/zendesk/cross-storage
thank you! This definitely seems to open up a path that I can look into. As for custom protocol handlers, their experience is pretty messy. But well, try and use what you've got eh.
AFAIK this is the kind of thing Web Intents was meant to facilitate:
https://en.wikipedia.org/wiki/Web_Intents
Too bad it seems to be dead.
https://en.wikipedia.org/wiki/Web_Intents
Too bad it seems to be dead.
yep. when I stumbled on this I was all yeyy. Then I saw the status and was all "sigh". That led me to custom URL protocols which turned out to be a deadend
Well, in a distributed twitter everyone is primarily writing to their own server. "Retweets" are just a different kind of content. Notification of the originating server that you've found something interesting should be an optional nicety, not a critical feature. Chances are most sites won't support that feature anyway (to easy to abuse for spam).
I prefer a Human at the other end
The scenario is this:
Person A and Person B host their own versions of an open source version of twitter on persona.com and personb.com respectively. Each person is currently logged into their own app and are happily "tweeting". Person A discovers person B's site and sees a tweet they'd like to reshare. Upon clicking reshare, Person A's app should make a request to Person B's app saying "I'm resharing". Person B's app would respond saying "ok. here's the tweet you are resharing along with other meta info. I just increased my reshare count to 1". Obviously this would happen over an open standard API.
The kicker here though is, when person A clicks reshare on person B's site, how does the browser know that persona.com should initiate a request? How does it get the token from person A (so that no one can manually craft their own requests to get person A to reshare) and say "fine, it's person A who wants to do this reshare"?
Right now I'm stuck at the point where it feels like some central medium has to be watching over both sites so the intermediate request would go to central server saying "hey, this token (no idea who it is) just said it wants to reshare person B's tweet". The central server would match token to person A, and say "hey persona.com, you need to do a reshare on this tweet" from which point all would function as normal.
I desperately want to remove the central server but current protocols just don't seem to allow for it. Funnily enough, this would be simple on a mobile/desktop app. But on a browser app I'm completely stuck. Once person A leaves persona.com, the browser has no way of knowing that it should contact persona.com with a token when reshare is clicked.
Is a central server really the only way to go about this?