Hi Jeremy, I've got lots to learn about ipfs still, and the implementation(s) of it are evolving quickly. The web-gateways look just like servers, as you say, with distributed storage, but if we use ipfs directly, shouldn't we be able to treat each other's files as if they were on the same file-system? I'm anyway imagining more value in having individual tiddlers stored as separate objects and each wiki acting as a manifest to pull them off the network, like in the current node configuration - then sharing content and pub/sub seems quite straightforward. In the mean time I am interested in seeing if I could get orbit.db <https://github.com/haadcode/orbit-db> to work in the same way that other people have used couch/pouch.
With regards to twederation as currently implemented, is it possible to sandbox the incoming content so that it can't run code, for example? Otherwise it's always going to be vulnerable to injection attacks, no? There are presumably some safeguards we could implement, such as not allowing imported content to carry system tags. Also, I really don't know much about them, but might it also be possible to use a web-worker to load the remote wiki, instead of an iframe within the page? Regards, Richard On Saturday, June 25, 2016 at 9:10:20 PM UTC+10, Jeremy Ruston wrote: > > Hi Everyone > > Just to confirm what has already been said: > > * The SFT plugin relied on the way that older browsers were more relaxed > about allowing xmlhttprequest to be used to extract content from remote URIs > * The spark for the current TWederation work was the discovery that we > could get around that problem by loading the remote wiki in an iframe and > then using window.postMessage() to communicate between them. There are many > limitations to the technique, as Jed has outlined, but it is entirely HTML5 > compliant, and therefore as future proof as anything can be > * TWederation is thus independent of IPFS: IPFS gives us distributed > hosting but still looks like a server to the browser. As far as I can tell, > we would need the same iframe/postMessage technique to allow one IPFS > hosted wiki to load content from another. If xmlhttprequest were to work in > that situation then we could use it instead of the iframe/postMessage > technique, but the remainder of the TWederation approach and protocols > would still be relevant > * Mark’s suggestion of making the imported tiddlers be volatile (so that > they don’t get saved) could easily be done if TWederation were to package > imported tiddlers in a dynamically created plugin in the $:/temp namespace; > the imported tiddlers would then appear as shadow tiddlers > > Best wishes > > Jeremy > > > On 24 Jun 2016, at 23:41, 'Mark S.' via TiddlyWiki < > [email protected] <javascript:>> wrote: > > Maybe that's how the SFT did it. With the SFT, you could make the content > of another wiki temporarily available just as if it were part of your TW > (except you couldn't write to the tiddlers). Then you could disconnect when > you were done and your original TW would be back the way it was. > > Is the saver filter something that's easily available ? > > Thanks, > Mark > > > On Friday, June 24, 2016 at 12:51:15 PM UTC-7, Jed Carty wrote: >> >> What do you mean 'currently it actually brings in everything that is >> imported'? I am not sure how else you would import something. Do you mean >> temporary tiddlers that the wiki can interact with but aren't actually >> saved? Because that could be done pretty simply by making the widget use >> some field to indicate that something was imported and then have the saver >> ignore those tiddlers. It would just be a matter of creating a new import >> type on the twederation side and editing the saver filter or whatever it is >> called in your wiki. >> > > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWiki" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To post to this group, send email to [email protected] > <javascript:>. > Visit this group at https://groups.google.com/group/tiddlywiki. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/8e22c4ac-f333-4fa2-8929-43ccf08d5061%40googlegroups.com > > <https://groups.google.com/d/msgid/tiddlywiki/8e22c4ac-f333-4fa2-8929-43ccf08d5061%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/59f3ea75-f9b0-4533-8847-bbd7f980a694%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
