Hi Jeremy, Sounds very exciting. It seems I have a bunch of learning curves to ascend.
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. 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. 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 > > 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 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/ >> >> >> Yes, the docs at tiddlywiki.com (and 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> - 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 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 [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/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. >> >> >> > -- > 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/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. > > > -- 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/aaf36897-a263-46ab-9cda-2b94715f2c1b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
