Hi Mark > Sounds very exciting. It seems I have a bunch of learning curves to ascend.
>From the perspective of a user, Xememex behaves almost exactly like the stock >Node.js configuration of TiddlyWiki. > The thing about cloud-based services, is there is just no way for you to know > what's going on behind the scenes. Evernote does most everything I want, has > limitless capacity and is reasonably priced. Of course it can't slice and > dice like TW, but it can suck entire articles including images and formatting > all at once. BUT ... I'm reluctant to use it for personal data. Especially > since the shell-shock exploit. In theory, every cloud-based service should be > shutting down their machines and applying a firmware patch that will actually > reduce the performance of their machines. But are they? Without the patch, > one rogue client might be able to capture the data of 1000s of other clients. Cloud-based services aren’t suitable for everybody all of the time. The trade-off is that one gains scalability, availability, and access to a bunch of useful “black box” functionality. Personally, I use a mix of cloud services and things running on my own machines. AWS have patched Shell Shock and the flaws that were reported earlier this year. But it would be prudent to assume that similar issues will be found in the future. But of course, part of the point of TiddlyWiki is that one can use it in a rigorously private manner, and that capability is not going away. The possibility of using the same app across such a wide spectrum of contexts is pretty unique. > What would make me more comfortable with cloud-based services if client-side > encryption were available. I know that nixes some of the big data > possibilities (but not all, if meta data is available) but it would make > people feel more comfortable. Also, if the corporations you work with have > HIPAA-like requirements, internal encryption would be pretty much mandatory. A subset of AWS services are HIPAA-compliant; including supporting encryption for data at rest. There’s no obstacle with using client side encryption with Xememex or any other TW serverside; it just needs some work on the client to make things work. Best wishes Jeremy. > > Thanks! > -- Mark > > On Friday, March 9, 2018 at 3:47:15 AM UTC-8, Jeremy Ruston wrote: > Hi Tony, Mark, > > > I hope this doesn't mean that the stand-alone TW won't lose it's support > > and/or interest. > > Not at all. TiddlyWiki is the main component of Xememex. Or put another way, > Xememex is just another platform on which TiddlyWiki can run (alongside > Node.js, the browser, TiddlyDesktop etc). > > The guts are actually already open source — see the plugin: > > https://github.com/Jermolene/TiddlyWiki5/tree/master/plugins/tiddlywiki/aws > <https://github.com/Jermolene/TiddlyWiki5/tree/master/plugins/tiddlywiki/aws> > > It can take a wiki folder and package it up as a single JS file that can be > executed within Amazon’s Lambda environment. The heart of Xememex is just > running TiddlyWiki as a Lambda function in Amazon’s cloud. > > > Just to get past the sticker shock, about how much does Amazon charge for > > say 20 active contributors and a drive-by load equivalent to what > > TiddlyWiki.com <http://tiddlywiki.com/> gets now? > > One would need to break that down to the level of individual Lambda > executions and data accesses in order to do a robust estimate, but it > wouldn’t be very much. > > It’s important to understand is that AWS pricing is incredibly cheap, and > getting cheaper all the time. For any given load it’s pretty much always > cheaper than a dedicated server would be. What requires a different way of > thinking is that in the old world of servers one provisioned a service by > choosing the server one could afford. The service would then scale up to the > capacity of that server, and when saturated it would fail in some way. The > advantage of that architecture is that you have a cap on the monthly costs > because the cost of the server is fixed. > > In serverless environments like AWS you don’t have that cap. If demand grows, > the infrastructure just keeps scaling. It’s incredibly useful; I had a task > that was taking 20 minutes to perform as a sequence of four or five Lambdas, > and I was able to reduce the execution time to 20 seconds just by splitting > the work into 200 parallel lambdas. The ultimate promise of running > TiddlyWiki in the cloud is that we will be able to use it for the kind of > “big data” projects that overwhelm TiddlyWiki running on a single machine. > > Anyhow, we do have one important capability to limit runaway costs which is > that Amazon includes a content delivery network that caches static content at > the edge of the network. That avoids the crippling costs associated with, > say, being featured on a high traffic website like HackerNews or SlashDot. > >> I hope this amazon solution could be open, because many of us may be >> prepared to host our own shared environments on Amazon ourselves, even at >> some cost. > > Some of the new components I’ve built for Xememex are already open sourced, > and I’ll continue to open source stuff as it makes sense. > >> Not withstanding that for community access solutions that have back-end >> costs please never underestimate community contributions from Crowd funding >> (initial and ongoing) Patrion to optional donations and tip jars to fund >> such services. The addition of a target that shows % funding raised can also >> be helpful. > > I’m enthusiastic about using crowd funding to kickstart a business or social > enterprise, but I know from friends who have done it successfully that it > requires a lot of time and attention to get it right. Patreon is a bit more > interesting because it focusses on managing ongoing revenue, and seems ideal > for covering running costs of some modest community infrastructure. > > I have not explored community funding along those lines because I would still > need to be doing something else commercial to earn an income. So, my current > approach is a commercial initiative: trying to build a sustainable business > by offering other businesses and individuals a professionally managed cloud > TiddlyWiki service. > >> Non coercive opportunities to fund community projects is not >> commercialisation, it is simply permitting the community to empower itself. > > Absolutely. I should have said that one of the simplest models I can see for > funding community infrastructure would be to simply ask people signing up to > donate as much as they can afford of a suggested donation. If we find that > we’re coming up short then we can have a funding drive and try to drum up > more donations. As you note, services like Patreon have made it easy to > manage that sort of thing. I’d be pretty confident that we could cover the > costs in that way. > > But, I’m pretty bad with money, and the prospect of managing cash for the > community rather terrifies me. > >> Perhaps larger larger than plugin solutions such as tiddlyDesktop, >> TiddlyAmazon should have a one of or reoccurring contribution option, >> regular contributors could then post an I Support TiddlyWiki (financially) >> certificate on their site, which also promotes TiddlyWiki and further >> donations. > > If Federatial were doing well enough out of offering Xememex as a commercial > TiddlyWiki cloud hosting service then it would be entirely appropriate that > Federatial should donate the community hosting services. > >> If surpluses occur you can return to the community with awards and >> commissions for key deliverables. > > We have talked about this in the past, and it’s an attractive idea, but it > turns out that few open source projects have made this work well for them. > More common is to have commercial activity layered on top of an open source > ecosystem that is in turn donated by the major players in that commercial > activity. > > If Xememex is commercially successful then of course Federatial can fund > further development of TiddlyWiki by paying developers from the community, > and that’s something I’d love to do. > > Anyhow, my interest in all of this is really driven by the new capabilities > that TiddlyWiki can gain when you put it in the cloud.: > > * first and foremost being ease of use; TiddlyWiki in the cloud can be as > easy to use as any online service > * adding a tiddler by sending an email to a special email address > * real time notifications via SMS/email etc > * integration of other online services: image recognition, OCR, speech > transcription, automatic translation services > * scability to cope with millions of tiddlers > > I love the prospect of having all those facilities, and still being able to > download a wiki to work on it offline, or to perform destructive experiments > on it without disturbing the original. > > Best wishes > > Jeremy. > >> >> Regards >> Tony >> >> On Friday, March 9, 2018 at 8:49:59 AM UTC+11, Jeremy Ruston wrote: >> Hi Everyone >> >>> 1) Is there a "definitive" TW (definitive in the sense that it serves as >>> some kind of master >>> reference copy for documentation of how TW works -- I'm assuming this is at >>> https://tiddlywiki.com/ <https://tiddlywiki.com/> >> >> Yes, the docs at tiddlywiki.com <http://tiddlywiki.com/> (and >> tiddlywiki.com/dev <http://tiddlywiki.com/dev>) are intended to be the >> authoritative reference docs for TiddlyWiki. >> >> The reference docs live in GitHub so that they are in lockstep with the >> code; one can check out an old version and be confident that the docs will >> line up with the code. >> >> The contribution process to GitHub is indeed too complex for casual users. >> I’d like to tackle it in several ways: >> >> * To take the non-reference docs out of the TW repo, and provide a lower >> friction path for contributions (eg Google Forms, or a custom server app - >> see below) >> * To make it easier to contribute directly to GitHub using something like >> this new JS library that runs in the browser: >> <https://github.com/octokit/rest.js <https://github.com/octokit/rest.js>> - >> users might only visit GitHub to create their account, and then perform >> everything else through the TW UI >> >> We’ve also got some work underway to speed up the deployment process through >> a continuous integration build server. >> >>> 2) Every wikipedia has a Talk page - for discussions about a page. >>> This seems like a good idea - currently the only way to comment on a page >>> is to make a better version and send a push request to github -- this seems >>> a bit awkward >> >> I agree that it would be useful for the same reason as Wikipedia. >> >> The aspiration we’ve long discussed is to have a federated discussion >> community based on a mix of P2P tech (Dat/Beaker), centralised services, and >> personal servers. >> >>> Case in point :the SetWidget has an example saying >>> >>> >>> <$set name="myVariable" value="Some text"> >>> <$text text=<<myVariable>>/> >>> </$set> >>> >>> But the text says name is a variable - but the <<myVariable>> is a macro >>> expansion. >>> So here set has defined a macro. The Variable tiddler talks about 'special >>> types of variable’ >> >> The double angle brackets when used as the quotes for an attribute cause it >> to be interpreted as a transclusion of the raw text of a variable; using the >> double angle brackets syntax as an element will transclude the variable and >> also “wikify” it (parse and render it). >> >>> What I've wondered, and asked before, is whether it is legal/acceptable to >>> import the content of TiddlyWiki.com <http://tiddlywiki.com/> into such a >>> wiki. If not, it would take years to generate comparable material. >> >> Absolutely, yes, the documentation content on tiddlywiki.com >> <http://tiddlywiki.com/> is licensed under the same BSD license as the code >> (because we’re treating the docs as part of the code). Remixing the >> documentation is positively encouraged. >> >>> All this is why having a real stand-alone wiki would be so much more >>> expeditious. But it would take forever to populate if you couldn't grab an >>> existing information source as a starting point. >> >> This is our million dollar question, and has been for some time. Things are >> changing, though. As I think I’ve mentioned elsewhere, over the last 18 >> months I have built a scalable TiddlyWiki serverside based on Amazon’s cloud >> services, called Xememex. For the old timers, it’s like TiddlySpace, except >> that I can run a batch script and create a whole new instance in just a few >> minutes. >> >> It’s what I’ve wanted to make with TiddlyWiki for many years: a traditional >> multi-user TiddlyWiki, with user accounts, authentication, access control, >> and the ability to build lightweight static pages from tiddlers. >> >> I’ve funded the development through the consultancy work I’ve been doing >> through my company Federatial. It’s now reached the point where it could >> support either or both of our community documentation efforts and our >> discussion requirements, and we could consider whether we wanted to adopt it. >> >> The challenge is that this cloud infrastructure costs money to run; Amazon’s >> web services are billed by usage, so there’s no charge for an app or site >> when nobody is using it, but conversely the charges can rise rapidly with >> heavy usage. >> >> The idea of charging users money to participate in the TiddlyWiki community >> is unacceptable to me (because — duh! — I think I learn so much from the >> community that if anything I should be paying them/you, and not the other >> way around). >> >> Anyhow, it’s a good time to be talking about this. >> >> Best wishes >> >> Jeremy. >> >> >>> >>> Cheers >>> >>> /Joe >>> >>> >>> >>> >>> -- >>> 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 tiddlywiki+...@ <>googlegroups.com <http://googlegroups.com/>. >>> To post to this group, send email to tiddl...@ <>googlegroups.com >>> <http://googlegroups.com/>. >>> Visit this group at https://groups.google.com/group/tiddlywiki >>> <https://groups.google.com/group/tiddlywiki>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/tiddlywiki/5a5fcc58-adf3-4ac3-8b27-a38a639346bc%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/tiddlywiki/5a5fcc58-adf3-4ac3-8b27-a38a639346bc%40googlegroups.com?utm_medium=email&utm_source=footer>. >>> For more options, visit https://groups.google.com/d/optout >>> <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 tiddlywiki+...@ <>googlegroups.com <http://googlegroups.com/>. >> To post to this group, send email to tiddl...@ <>googlegroups.com >> <http://googlegroups.com/>. >> Visit this group at https://groups.google.com/group/tiddlywiki >> <https://groups.google.com/group/tiddlywiki>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/tiddlywiki/efa622c9-d174-4dbf-822d-2f252aeec819%40googlegroups.com >> >> <https://groups.google.com/d/msgid/tiddlywiki/efa622c9-d174-4dbf-822d-2f252aeec819%40googlegroups.com?utm_medium=email&utm_source=footer>. >> For more options, visit https://groups.google.com/d/optout >> <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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/tiddlywiki > <https://groups.google.com/group/tiddlywiki>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/aaf36897-a263-46ab-9cda-2b94715f2c1b%40googlegroups.com > > <https://groups.google.com/d/msgid/tiddlywiki/aaf36897-a263-46ab-9cda-2b94715f2c1b%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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/68AEA242-5447-400C-9CA4-6C2BCA545F04%40gmail.com. For more options, visit https://groups.google.com/d/optout.
