[tw5] Re: More playing around with TiddlyWiki on node.js: the makings of a distributed database

[Charlie Veniot]

Well, throwing out the general concepts for now.  The full guacamole isn't 
really mine to share at the moment.

On Monday, September 6, 2021 at 2:46:03 AM UTC-3 TW Tones wrote:

> Thanks for sharing your solution to the community.
>
> On Monday, 6 September 2021 at 15:42:25 UTC+10 cj.v...@gmail.com wrote:
>
>> G'day Tones,
>>
>> Nah, in this scenario I've dreamed up (to really get to know TiddlyWiki 
>> on node.js), I'm sticking to a minimalist approach and not adding any 
>> plugins or extras, pushing as far as I can with just TiddlyWiki and a 
>> little bit of help via symlinks.
>>
>> In this scenario, each sales rep has access to just his/her TiddlyWiki, 
>> private yet having shareable bits.  Distributed data, with clear ownership 
>> of data (of customer files).
>>
>> Each sales rep deals with only one TiddlyWiki, and no futzing about with 
>> drag and drop of tiddlers from one wiki to another.
>>
>> No multi-user TiddlyWikis, no sharing of tiddlers except for view-only 
>> tiddlers that have lists of customers.
>>
>> Ultimately, users will have no clue they are using TiddlyWiki.  It will 
>> feel and look just like any database application.
>>
>> At the moment, still looks like TiddlyWiki as I iron out the overall 
>> architecture first.  It is looking pretty cool so far.  
>>
>> So far includes (short list):
>>
>>- Architecture/Framework/System TiddlyWiki
>>   - Including edited Tiddler "Save" and "Delete" to do extra actions 
>>   upon save and delete of tiddlers tagged customer
>>   - Tiddler Locking mechanism to prevent editing/deletion of 
>>   tiddlers from this TiddlyWiki
>>- "Big DB" TiddlyWiki
>>   - This TiddlyWiki has nothing but symlinks to each of the customer 
>>   list JSON tiddlers for each SalesRep TiddlyWiki
>>   - By including this TiddlyWiki, each of the Sales Rep TiddlyWikis 
>>   gets the aggregated list of all customers from all sales reps
>>- Individual Sales Rep TiddlyWikis
>>   - These include the first two TiddlyWikis
>>   - Every time a new customer gets added/edited/deleted or loses the 
>>   "customer" tag, that sales rep's customer list JSON gets updated
>>
>> Yeah, pretty cool setup for a shoe-string budget scenario.
>>
>> All happily running on my Chromebook.  Gets my geek mojo going something 
>> silly.
>> On Monday, September 6, 2021 at 1:11:27 AM UTC-3 TW Tones wrote:
>>
>>> Charlie,
>>>
>>> Have you considered creating a third node Wiki "Customer List", using 
>>> bob so more than one user can access it at a time?
>>>
>>> Then both Sales Reps wikis can have this  "Customer List" in a tiddler 
>>> with and an iframe to the customer list and freely drag "customer" tiddlers 
>>> to and from the customer list. If you provision, "add new customers" only 
>>> in the customer list, then it will always be used for new customers and 
>>> remain the primary "source of truth". From which all sales reps obtain the 
>>> customer details.
>>>
>>> Regards
>>> Tones
>>>
>>> On Sunday, 5 September 2021 at 07:07:55 UTC+10 cj.v...@gmail.com wrote:
>>>
 Oops, errata:

 The other sales rep (say Sales Rep 2) has a file in the tiddlers folder 
 that is a symlink to the "Sales Rep 1 Customer List."  So that sales rep 
 has his/her own view-only "Sales Rep 2 Customer List" that gets updated 
 (automatically and behind the scenes) upon new/edit/delete of customer 
 tiddlers, and also has view access to "Sales Rep *1* *(not 2)* Customer 
 List".

 On Saturday, September 4, 2021 at 5:53:52 PM UTC-3 Charlie Veniot wrote:

> Say I have two sales reps, each with his/her own private TiddlyWiki on 
> node.js.
>
> Neither sales rep has access of any kind to the other sales rep's 
> TiddlyWiki.
>
> However, each sales rep does have view access to one tiddler from the 
> other sales rep's TiddlyWiki: other sales rep's list of customers.
>
> When a sales rep saves a new customer tiddler, the save process 
> updates (behind the scenes and upon any new/edit/delete of a customer) 
> that 
> sales rep's customer list tiddler (say "Sales Rep 1 Customer List"), a 
> view-only json data tiddler, with each index being kind of like a 
> comma-separated-value record for a customer.
>
> The other sales rep (say Sales Rep 2) has a file in the tiddlers 
> folder that is a symlink to the "Sales Rep 1 Customer List."  So that 
> sales 
> rep has his/her own view-only "Sales Rep 2 Customer List" that gets 
> updated 
> (automatically and behind the scenes) upon new/edit/delete of customer 
> tiddlers, and also has view access to "Sales Rep 2 Customer List".
>
> So each sales rep has access to their own customer tiddlers, but also 
> has access to his/her own customer list + the other sales rep's customer 
> list, which can then be merged into a consolidated customer list.
>
> Essentially, each 

[tw5] Re: Can a tiddler be setup to not allow being overwritten?

[Charlie Veniot]

Well, "Tiddly Locking" isn't a solution to my problem in this thread.

My problem is about preventing tiddlers from being overwritten by an import 
or by a new tiddler getting created and saved with a name of a tiddler that 
already exists.  That's not solved.

Tiddly Locking is great, is something I use, but has nothing to do with 
this thread.

On Monday, September 6, 2021 at 2:34:45 AM UTC-3 TW Tones wrote:

> Charlie,
>
> Good to hear. Since you question was answered with "Tiddly locking" could 
> you point to that as a solution for future readers in this thread ?
>
> Tones
>
> On Monday, 6 September 2021 at 15:15:49 UTC+10 cj.v...@gmail.com wrote:
>
>> G'day Tones,
>>
>> I've got editing and delete of important tiddlers blocked via tiddler 
>> locking.  That's easy and good.
>>
>> The only thing I have to handle, even if 99% unlikely, is certain 
>> tiddlers getting overwritten by any tech-savvy (well, TiddlyWiki-savvy) 
>> individual.
>>
>> Since that can't really be prevented, then a scheduled process to compare 
>> files should be pretty easy (for all of these TiddlyWiki instances on 
>> node.js)  Just a matter of comparing "end-user" tiddlers to 
>> "architecture/infrastructure/farm/admin/etc .) tiddlers, and having the 
>> process delete anything that shouldn't exist in end-users' tiddler folders.
>>
>> Maybe another little process to raise the redflag as soon as there's a 
>> blip.
>>
>> I am avoiding plugins and staying pure node.js and tiddlywiki for as much 
>> as I can, an exercise to really get a good feel for how TiddlyWiki works on 
>> node.js.  For the near future.
>>
>> All of these goodies you mention in my back-pocket for now.  Thanks !
>> On Monday, September 6, 2021 at 1:03:27 AM UTC-3 TW Tones wrote:
>>
>>> Charlie,
>>>
>>> A few ideas;
>>>
>>> One way would be to stash a copy away, perhaps inside a JSON tiddler,  
>>> similar to Mohammad's trash plugin but just on editing. This kind of 
>>> solution can intercept User interface edit/delete however batch processes 
>>> can by pass this. 
>>>
>>> Some solutions like noteself to keep all versions, so you could restore 
>>> from there, after running an automated are tiddlers missing check, perhaps 
>>> before saving.
>>>
>>> You could also modify the delete button to refuse to delete if a tiddler 
>>> contains a field delete-inhibit=yes or just exists. I have already made an 
>>> alternate edit button which honors edit-inhibit and just hide the original 
>>> edit behind the more button. On some wikis we may want to hide the more 
>>> button so they can not access (directly) the buttons we do not want them to 
>>> use and only provide them alternatives, we want them to use. When the cant 
>>> edit or delete you can actually just hide that alternative button.
>>>
>>> Another is to take a set of tiddlers, and move them into a plugin, 
>>> delete the tiddler version. They then become shadows, and if edited you 
>>> simply delete the tiddler to return to the shadow copy. The only way to 
>>> delete the shadows is to delete the plugin itself, so the user needs to 
>>> undertake additional steps. This can avoid batch processes deleting the 
>>> tiddlers.
>>>
>>> I have felt that for some time introducing delete-inhibit and 
>>> edit-inhibit fields/flags on at least some tiddlers would be a helpful 
>>> option. For example the plugin mentioned in the last paragraph.
>>>
>>> I am yet to work out how but I believe the new eventCatcher widget or 
>>> the existing LinkCatcherWidget or ActionConfirmWidget can help here.
>>>
>>> One idea would be trapping using the action confirm widget on the delete 
>>> step, and on confirmation make a backup copy of the tiddler.
>>>
>>> Tones
>>>
>>> On Monday, 6 September 2021 at 11:01:25 UTC+10 cj.v...@gmail.com wrote:
>>>
 Trying to achieve a robust architecture for a farm of node.js 
 TiddlyWikis that together form a distributed database, with end-user level 
 (and private) TiddlyWikis that have certain types of tiddlers that are 
 automagically shared (and the rest private), and system-level TiddlyWikis 
 that tie all of the architecture together along with user-interface stuff, 
 etc. etc. etc.

 Sure, not very likely end-user folk could muck things up, but a robust 
 system really should never allow an end-user to break their TiddlyWiki (in 
 this farm idea of mine) by somehow replacing any key component tiddler.

 No worries.  I'll train my thoughts on obfuscation, risk-mitigation 
 design/strategies, and automated monitoring/repairing processes.

 All part of a big idea that ties together, in part:

- A brewing idea: TiddlyWiki on node.js: check for changes 

- More playing around with TiddlyWiki on node.js: the makings of a 
distributed database 


 On 

[tw5] Re: More playing around with TiddlyWiki on node.js: the makings of a distributed database

[TW Tones]

Thanks for sharing your solution to the community.

On Monday, 6 September 2021 at 15:42:25 UTC+10 cj.v...@gmail.com wrote:

> G'day Tones,
>
> Nah, in this scenario I've dreamed up (to really get to know TiddlyWiki on 
> node.js), I'm sticking to a minimalist approach and not adding any plugins 
> or extras, pushing as far as I can with just TiddlyWiki and a little bit of 
> help via symlinks.
>
> In this scenario, each sales rep has access to just his/her TiddlyWiki, 
> private yet having shareable bits.  Distributed data, with clear ownership 
> of data (of customer files).
>
> Each sales rep deals with only one TiddlyWiki, and no futzing about with 
> drag and drop of tiddlers from one wiki to another.
>
> No multi-user TiddlyWikis, no sharing of tiddlers except for view-only 
> tiddlers that have lists of customers.
>
> Ultimately, users will have no clue they are using TiddlyWiki.  It will 
> feel and look just like any database application.
>
> At the moment, still looks like TiddlyWiki as I iron out the overall 
> architecture first.  It is looking pretty cool so far.  
>
> So far includes (short list):
>
>- Architecture/Framework/System TiddlyWiki
>   - Including edited Tiddler "Save" and "Delete" to do extra actions 
>   upon save and delete of tiddlers tagged customer
>   - Tiddler Locking mechanism to prevent editing/deletion of tiddlers 
>   from this TiddlyWiki
>- "Big DB" TiddlyWiki
>   - This TiddlyWiki has nothing but symlinks to each of the customer 
>   list JSON tiddlers for each SalesRep TiddlyWiki
>   - By including this TiddlyWiki, each of the Sales Rep TiddlyWikis 
>   gets the aggregated list of all customers from all sales reps
>- Individual Sales Rep TiddlyWikis
>   - These include the first two TiddlyWikis
>   - Every time a new customer gets added/edited/deleted or loses the 
>   "customer" tag, that sales rep's customer list JSON gets updated
>
> Yeah, pretty cool setup for a shoe-string budget scenario.
>
> All happily running on my Chromebook.  Gets my geek mojo going something 
> silly.
> On Monday, September 6, 2021 at 1:11:27 AM UTC-3 TW Tones wrote:
>
>> Charlie,
>>
>> Have you considered creating a third node Wiki "Customer List", using bob 
>> so more than one user can access it at a time?
>>
>> Then both Sales Reps wikis can have this  "Customer List" in a tiddler 
>> with and an iframe to the customer list and freely drag "customer" tiddlers 
>> to and from the customer list. If you provision, "add new customers" only 
>> in the customer list, then it will always be used for new customers and 
>> remain the primary "source of truth". From which all sales reps obtain the 
>> customer details.
>>
>> Regards
>> Tones
>>
>> On Sunday, 5 September 2021 at 07:07:55 UTC+10 cj.v...@gmail.com wrote:
>>
>>> Oops, errata:
>>>
>>> The other sales rep (say Sales Rep 2) has a file in the tiddlers folder 
>>> that is a symlink to the "Sales Rep 1 Customer List."  So that sales rep 
>>> has his/her own view-only "Sales Rep 2 Customer List" that gets updated 
>>> (automatically and behind the scenes) upon new/edit/delete of customer 
>>> tiddlers, and also has view access to "Sales Rep *1* *(not 2)* Customer 
>>> List".
>>>
>>> On Saturday, September 4, 2021 at 5:53:52 PM UTC-3 Charlie Veniot wrote:
>>>
 Say I have two sales reps, each with his/her own private TiddlyWiki on 
 node.js.

 Neither sales rep has access of any kind to the other sales rep's 
 TiddlyWiki.

 However, each sales rep does have view access to one tiddler from the 
 other sales rep's TiddlyWiki: other sales rep's list of customers.

 When a sales rep saves a new customer tiddler, the save process updates 
 (behind the scenes and upon any new/edit/delete of a customer) that sales 
 rep's customer list tiddler (say "Sales Rep 1 Customer List"), a view-only 
 json data tiddler, with each index being kind of like a 
 comma-separated-value record for a customer.

 The other sales rep (say Sales Rep 2) has a file in the tiddlers folder 
 that is a symlink to the "Sales Rep 1 Customer List."  So that sales rep 
 has his/her own view-only "Sales Rep 2 Customer List" that gets updated 
 (automatically and behind the scenes) upon new/edit/delete of customer 
 tiddlers, and also has view access to "Sales Rep 2 Customer List".

 So each sales rep has access to their own customer tiddlers, but also 
 has access to his/her own customer list + the other sales rep's customer 
 list, which can then be merged into a consolidated customer list.

 Essentially, each private TiddlyWiki on node.js, hosts CSV-like json 
 data tiddlers, and those data tiddlers are made shareable via symlinks, 
 and 
 all of the data tiddlers become components of a distributed database for 
 querying/reporting/whatever.

 Just throwing that out there in case anybody 

[tw5] Re: More playing around with TiddlyWiki on node.js: the makings of a distributed database

[Charlie Veniot]

G'day Tones,

Nah, in this scenario I've dreamed up (to really get to know TiddlyWiki on 
node.js), I'm sticking to a minimalist approach and not adding any plugins 
or extras, pushing as far as I can with just TiddlyWiki and a little bit of 
help via symlinks.

In this scenario, each sales rep has access to just his/her TiddlyWiki, 
private yet having shareable bits.  Distributed data, with clear ownership 
of data (of customer files).

Each sales rep deals with only one TiddlyWiki, and no futzing about with 
drag and drop of tiddlers from one wiki to another.

No multi-user TiddlyWikis, no sharing of tiddlers except for view-only 
tiddlers that have lists of customers.

Ultimately, users will have no clue they are using TiddlyWiki.  It will 
feel and look just like any database application.

At the moment, still looks like TiddlyWiki as I iron out the overall 
architecture first.  It is looking pretty cool so far.  

So far includes (short list):

   - Architecture/Framework/System TiddlyWiki
  - Including edited Tiddler "Save" and "Delete" to do extra actions 
  upon save and delete of tiddlers tagged customer
  - Tiddler Locking mechanism to prevent editing/deletion of tiddlers 
  from this TiddlyWiki
   - "Big DB" TiddlyWiki
  - This TiddlyWiki has nothing but symlinks to each of the customer 
  list JSON tiddlers for each SalesRep TiddlyWiki
  - By including this TiddlyWiki, each of the Sales Rep TiddlyWikis 
  gets the aggregated list of all customers from all sales reps
   - Individual Sales Rep TiddlyWikis
  - These include the first two TiddlyWikis
  - Every time a new customer gets added/edited/deleted or loses the 
  "customer" tag, that sales rep's customer list JSON gets updated
   
Yeah, pretty cool setup for a shoe-string budget scenario.

All happily running on my Chromebook.  Gets my geek mojo going something 
silly.
On Monday, September 6, 2021 at 1:11:27 AM UTC-3 TW Tones wrote:

> Charlie,
>
> Have you considered creating a third node Wiki "Customer List", using bob 
> so more than one user can access it at a time?
>
> Then both Sales Reps wikis can have this  "Customer List" in a tiddler 
> with and an iframe to the customer list and freely drag "customer" tiddlers 
> to and from the customer list. If you provision, "add new customers" only 
> in the customer list, then it will always be used for new customers and 
> remain the primary "source of truth". From which all sales reps obtain the 
> customer details.
>
> Regards
> Tones
>
> On Sunday, 5 September 2021 at 07:07:55 UTC+10 cj.v...@gmail.com wrote:
>
>> Oops, errata:
>>
>> The other sales rep (say Sales Rep 2) has a file in the tiddlers folder 
>> that is a symlink to the "Sales Rep 1 Customer List."  So that sales rep 
>> has his/her own view-only "Sales Rep 2 Customer List" that gets updated 
>> (automatically and behind the scenes) upon new/edit/delete of customer 
>> tiddlers, and also has view access to "Sales Rep *1* *(not 2)* Customer 
>> List".
>>
>> On Saturday, September 4, 2021 at 5:53:52 PM UTC-3 Charlie Veniot wrote:
>>
>>> Say I have two sales reps, each with his/her own private TiddlyWiki on 
>>> node.js.
>>>
>>> Neither sales rep has access of any kind to the other sales rep's 
>>> TiddlyWiki.
>>>
>>> However, each sales rep does have view access to one tiddler from the 
>>> other sales rep's TiddlyWiki: other sales rep's list of customers.
>>>
>>> When a sales rep saves a new customer tiddler, the save process updates 
>>> (behind the scenes and upon any new/edit/delete of a customer) that sales 
>>> rep's customer list tiddler (say "Sales Rep 1 Customer List"), a view-only 
>>> json data tiddler, with each index being kind of like a 
>>> comma-separated-value record for a customer.
>>>
>>> The other sales rep (say Sales Rep 2) has a file in the tiddlers folder 
>>> that is a symlink to the "Sales Rep 1 Customer List."  So that sales rep 
>>> has his/her own view-only "Sales Rep 2 Customer List" that gets updated 
>>> (automatically and behind the scenes) upon new/edit/delete of customer 
>>> tiddlers, and also has view access to "Sales Rep 2 Customer List".
>>>
>>> So each sales rep has access to their own customer tiddlers, but also 
>>> has access to his/her own customer list + the other sales rep's customer 
>>> list, which can then be merged into a consolidated customer list.
>>>
>>> Essentially, each private TiddlyWiki on node.js, hosts CSV-like json 
>>> data tiddlers, and those data tiddlers are made shareable via symlinks, and 
>>> all of the data tiddlers become components of a distributed database for 
>>> querying/reporting/whatever.
>>>
>>> Just throwing that out there in case anybody else geeks out on, as much 
>>> as I do, this kind of architectural experimentation.
>>>
>>

-- 
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 

[tw5] Re: Can a tiddler be setup to not allow being overwritten?

[TW Tones]

Charlie,

Good to hear. Since you question was answered with "Tiddly locking" could 
you point to that as a solution for future readers in this thread ?

Tones

On Monday, 6 September 2021 at 15:15:49 UTC+10 cj.v...@gmail.com wrote:

> G'day Tones,
>
> I've got editing and delete of important tiddlers blocked via tiddler 
> locking.  That's easy and good.
>
> The only thing I have to handle, even if 99% unlikely, is certain tiddlers 
> getting overwritten by any tech-savvy (well, TiddlyWiki-savvy) individual.
>
> Since that can't really be prevented, then a scheduled process to compare 
> files should be pretty easy (for all of these TiddlyWiki instances on 
> node.js)  Just a matter of comparing "end-user" tiddlers to 
> "architecture/infrastructure/farm/admin/etc .) tiddlers, and having the 
> process delete anything that shouldn't exist in end-users' tiddler folders.
>
> Maybe another little process to raise the redflag as soon as there's a 
> blip.
>
> I am avoiding plugins and staying pure node.js and tiddlywiki for as much 
> as I can, an exercise to really get a good feel for how TiddlyWiki works on 
> node.js.  For the near future.
>
> All of these goodies you mention in my back-pocket for now.  Thanks !
> On Monday, September 6, 2021 at 1:03:27 AM UTC-3 TW Tones wrote:
>
>> Charlie,
>>
>> A few ideas;
>>
>> One way would be to stash a copy away, perhaps inside a JSON tiddler,  
>> similar to Mohammad's trash plugin but just on editing. This kind of 
>> solution can intercept User interface edit/delete however batch processes 
>> can by pass this. 
>>
>> Some solutions like noteself to keep all versions, so you could restore 
>> from there, after running an automated are tiddlers missing check, perhaps 
>> before saving.
>>
>> You could also modify the delete button to refuse to delete if a tiddler 
>> contains a field delete-inhibit=yes or just exists. I have already made an 
>> alternate edit button which honors edit-inhibit and just hide the original 
>> edit behind the more button. On some wikis we may want to hide the more 
>> button so they can not access (directly) the buttons we do not want them to 
>> use and only provide them alternatives, we want them to use. When the cant 
>> edit or delete you can actually just hide that alternative button.
>>
>> Another is to take a set of tiddlers, and move them into a plugin, delete 
>> the tiddler version. They then become shadows, and if edited you simply 
>> delete the tiddler to return to the shadow copy. The only way to delete the 
>> shadows is to delete the plugin itself, so the user needs to undertake 
>> additional steps. This can avoid batch processes deleting the tiddlers.
>>
>> I have felt that for some time introducing delete-inhibit and 
>> edit-inhibit fields/flags on at least some tiddlers would be a helpful 
>> option. For example the plugin mentioned in the last paragraph.
>>
>> I am yet to work out how but I believe the new eventCatcher widget or the 
>> existing LinkCatcherWidget or ActionConfirmWidget can help here.
>>
>> One idea would be trapping using the action confirm widget on the delete 
>> step, and on confirmation make a backup copy of the tiddler.
>>
>> Tones
>>
>> On Monday, 6 September 2021 at 11:01:25 UTC+10 cj.v...@gmail.com wrote:
>>
>>> Trying to achieve a robust architecture for a farm of node.js 
>>> TiddlyWikis that together form a distributed database, with end-user level 
>>> (and private) TiddlyWikis that have certain types of tiddlers that are 
>>> automagically shared (and the rest private), and system-level TiddlyWikis 
>>> that tie all of the architecture together along with user-interface stuff, 
>>> etc. etc. etc.
>>>
>>> Sure, not very likely end-user folk could muck things up, but a robust 
>>> system really should never allow an end-user to break their TiddlyWiki (in 
>>> this farm idea of mine) by somehow replacing any key component tiddler.
>>>
>>> No worries.  I'll train my thoughts on obfuscation, risk-mitigation 
>>> design/strategies, and automated monitoring/repairing processes.
>>>
>>> All part of a big idea that ties together, in part:
>>>
>>>- A brewing idea: TiddlyWiki on node.js: check for changes 
>>>
>>>- More playing around with TiddlyWiki on node.js: the makings of a 
>>>distributed database 
>>>
>>>
>>> On Sunday, September 5, 2021 at 8:18:19 PM UTC-3 PMario wrote:
>>>
 On Sunday, September 5, 2021 at 8:36:26 PM UTC+2 cj.v...@gmail.com 
 wrote:
 ...

> Is there an easy way to protect such a tiddler?
>

 No. In TW you can overwrite every core tiddler if you like. So there is 
 no way to write-protect a tiddler. 
 What do you want to achieve?
 -m
  

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this 

[tw5] Re: Can a tiddler be setup to not allow being overwritten?

[Charlie Veniot]

G'day Tones,

I've got editing and delete of important tiddlers blocked via tiddler 
locking.  That's easy and good.

The only thing I have to handle, even if 99% unlikely, is certain tiddlers 
getting overwritten by any tech-savvy (well, TiddlyWiki-savvy) individual.

Since that can't really be prevented, then a scheduled process to compare 
files should be pretty easy (for all of these TiddlyWiki instances on 
node.js)  Just a matter of comparing "end-user" tiddlers to 
"architecture/infrastructure/farm/admin/etc .) tiddlers, and having the 
process delete anything that shouldn't exist in end-users' tiddler folders.

Maybe another little process to raise the redflag as soon as there's a blip.

I am avoiding plugins and staying pure node.js and tiddlywiki for as much 
as I can, an exercise to really get a good feel for how TiddlyWiki works on 
node.js.  For the near future.

All of these goodies you mention in my back-pocket for now.  Thanks !
On Monday, September 6, 2021 at 1:03:27 AM UTC-3 TW Tones wrote:

> Charlie,
>
> A few ideas;
>
> One way would be to stash a copy away, perhaps inside a JSON tiddler,  
> similar to Mohammad's trash plugin but just on editing. This kind of 
> solution can intercept User interface edit/delete however batch processes 
> can by pass this. 
>
> Some solutions like noteself to keep all versions, so you could restore 
> from there, after running an automated are tiddlers missing check, perhaps 
> before saving.
>
> You could also modify the delete button to refuse to delete if a tiddler 
> contains a field delete-inhibit=yes or just exists. I have already made an 
> alternate edit button which honors edit-inhibit and just hide the original 
> edit behind the more button. On some wikis we may want to hide the more 
> button so they can not access (directly) the buttons we do not want them to 
> use and only provide them alternatives, we want them to use. When the cant 
> edit or delete you can actually just hide that alternative button.
>
> Another is to take a set of tiddlers, and move them into a plugin, delete 
> the tiddler version. They then become shadows, and if edited you simply 
> delete the tiddler to return to the shadow copy. The only way to delete the 
> shadows is to delete the plugin itself, so the user needs to undertake 
> additional steps. This can avoid batch processes deleting the tiddlers.
>
> I have felt that for some time introducing delete-inhibit and edit-inhibit 
> fields/flags on at least some tiddlers would be a helpful option. For 
> example the plugin mentioned in the last paragraph.
>
> I am yet to work out how but I believe the new eventCatcher widget or the 
> existing LinkCatcherWidget or ActionConfirmWidget can help here.
>
> One idea would be trapping using the action confirm widget on the delete 
> step, and on confirmation make a backup copy of the tiddler.
>
> Tones
>
> On Monday, 6 September 2021 at 11:01:25 UTC+10 cj.v...@gmail.com wrote:
>
>> Trying to achieve a robust architecture for a farm of node.js TiddlyWikis 
>> that together form a distributed database, with end-user level (and 
>> private) TiddlyWikis that have certain types of tiddlers that are 
>> automagically shared (and the rest private), and system-level TiddlyWikis 
>> that tie all of the architecture together along with user-interface stuff, 
>> etc. etc. etc.
>>
>> Sure, not very likely end-user folk could muck things up, but a robust 
>> system really should never allow an end-user to break their TiddlyWiki (in 
>> this farm idea of mine) by somehow replacing any key component tiddler.
>>
>> No worries.  I'll train my thoughts on obfuscation, risk-mitigation 
>> design/strategies, and automated monitoring/repairing processes.
>>
>> All part of a big idea that ties together, in part:
>>
>>- A brewing idea: TiddlyWiki on node.js: check for changes 
>>
>>- More playing around with TiddlyWiki on node.js: the makings of a 
>>distributed database 
>>
>>
>> On Sunday, September 5, 2021 at 8:18:19 PM UTC-3 PMario wrote:
>>
>>> On Sunday, September 5, 2021 at 8:36:26 PM UTC+2 cj.v...@gmail.com 
>>> wrote:
>>> ...
>>>
 Is there an easy way to protect such a tiddler?

>>>
>>> No. In TW you can overwrite every core tiddler if you like. So there is 
>>> no way to write-protect a tiddler. 
>>> What do you want to achieve?
>>> -m
>>>  
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/f78c2971-14ad-4049-a023-1666bc0f35f7n%40googlegroups.com.

[tw5] Re: More playing around with TiddlyWiki on node.js: the makings of a distributed database

[TW Tones]

Charlie,

Have you considered creating a third node Wiki "Customer List", using bob 
so more than one user can access it at a time?

Then both Sales Reps wikis can have this  "Customer List" in a tiddler with 
and an iframe to the customer list and freely drag "customer" tiddlers to 
and from the customer list. If you provision, "add new customers" only in 
the customer list, then it will always be used for new customers and remain 
the primary "source of truth". From which all sales reps obtain the 
customer details.

Regards
Tones

On Sunday, 5 September 2021 at 07:07:55 UTC+10 cj.v...@gmail.com wrote:

> Oops, errata:
>
> The other sales rep (say Sales Rep 2) has a file in the tiddlers folder 
> that is a symlink to the "Sales Rep 1 Customer List."  So that sales rep 
> has his/her own view-only "Sales Rep 2 Customer List" that gets updated 
> (automatically and behind the scenes) upon new/edit/delete of customer 
> tiddlers, and also has view access to "Sales Rep *1* *(not 2)* Customer 
> List".
>
> On Saturday, September 4, 2021 at 5:53:52 PM UTC-3 Charlie Veniot wrote:
>
>> Say I have two sales reps, each with his/her own private TiddlyWiki on 
>> node.js.
>>
>> Neither sales rep has access of any kind to the other sales rep's 
>> TiddlyWiki.
>>
>> However, each sales rep does have view access to one tiddler from the 
>> other sales rep's TiddlyWiki: other sales rep's list of customers.
>>
>> When a sales rep saves a new customer tiddler, the save process updates 
>> (behind the scenes and upon any new/edit/delete of a customer) that sales 
>> rep's customer list tiddler (say "Sales Rep 1 Customer List"), a view-only 
>> json data tiddler, with each index being kind of like a 
>> comma-separated-value record for a customer.
>>
>> The other sales rep (say Sales Rep 2) has a file in the tiddlers folder 
>> that is a symlink to the "Sales Rep 1 Customer List."  So that sales rep 
>> has his/her own view-only "Sales Rep 2 Customer List" that gets updated 
>> (automatically and behind the scenes) upon new/edit/delete of customer 
>> tiddlers, and also has view access to "Sales Rep 2 Customer List".
>>
>> So each sales rep has access to their own customer tiddlers, but also has 
>> access to his/her own customer list + the other sales rep's customer list, 
>> which can then be merged into a consolidated customer list.
>>
>> Essentially, each private TiddlyWiki on node.js, hosts CSV-like json data 
>> tiddlers, and those data tiddlers are made shareable via symlinks, and all 
>> of the data tiddlers become components of a distributed database for 
>> querying/reporting/whatever.
>>
>> Just throwing that out there in case anybody else geeks out on, as much 
>> as I do, this kind of architectural experimentation.
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/e72da75d-a563-41ce-92ea-9176c68b4cc3n%40googlegroups.com.

[tw5] Re: Can a tiddler be setup to not allow being overwritten?

[TW Tones]

Charlie,

A few ideas;

One way would be to stash a copy away, perhaps inside a JSON tiddler,  
similar to Mohammad's trash plugin but just on editing. This kind of 
solution can intercept User interface edit/delete however batch processes 
can by pass this. 

Some solutions like noteself to keep all versions, so you could restore 
from there, after running an automated are tiddlers missing check, perhaps 
before saving.

You could also modify the delete button to refuse to delete if a tiddler 
contains a field delete-inhibit=yes or just exists. I have already made an 
alternate edit button which honors edit-inhibit and just hide the original 
edit behind the more button. On some wikis we may want to hide the more 
button so they can not access (directly) the buttons we do not want them to 
use and only provide them alternatives, we want them to use. When the cant 
edit or delete you can actually just hide that alternative button.

Another is to take a set of tiddlers, and move them into a plugin, delete 
the tiddler version. They then become shadows, and if edited you simply 
delete the tiddler to return to the shadow copy. The only way to delete the 
shadows is to delete the plugin itself, so the user needs to undertake 
additional steps. This can avoid batch processes deleting the tiddlers.

I have felt that for some time introducing delete-inhibit and edit-inhibit 
fields/flags on at least some tiddlers would be a helpful option. For 
example the plugin mentioned in the last paragraph.

I am yet to work out how but I believe the new eventCatcher widget or the 
existing LinkCatcherWidget or ActionConfirmWidget can help here.

One idea would be trapping using the action confirm widget on the delete 
step, and on confirmation make a backup copy of the tiddler.

Tones

On Monday, 6 September 2021 at 11:01:25 UTC+10 cj.v...@gmail.com wrote:

> Trying to achieve a robust architecture for a farm of node.js TiddlyWikis 
> that together form a distributed database, with end-user level (and 
> private) TiddlyWikis that have certain types of tiddlers that are 
> automagically shared (and the rest private), and system-level TiddlyWikis 
> that tie all of the architecture together along with user-interface stuff, 
> etc. etc. etc.
>
> Sure, not very likely end-user folk could muck things up, but a robust 
> system really should never allow an end-user to break their TiddlyWiki (in 
> this farm idea of mine) by somehow replacing any key component tiddler.
>
> No worries.  I'll train my thoughts on obfuscation, risk-mitigation 
> design/strategies, and automated monitoring/repairing processes.
>
> All part of a big idea that ties together, in part:
>
>- A brewing idea: TiddlyWiki on node.js: check for changes 
>
>- More playing around with TiddlyWiki on node.js: the makings of a 
>distributed database 
>
>
> On Sunday, September 5, 2021 at 8:18:19 PM UTC-3 PMario wrote:
>
>> On Sunday, September 5, 2021 at 8:36:26 PM UTC+2 cj.v...@gmail.com wrote:
>> ...
>>
>>> Is there an easy way to protect such a tiddler?
>>>
>>
>> No. In TW you can overwrite every core tiddler if you like. So there is 
>> no way to write-protect a tiddler. 
>> What do you want to achieve?
>> -m
>>  
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/c5073b5f-d0b0-452b-8cbe-87ad12020d52n%40googlegroups.com.

[tw5] Re: Can a tiddler be setup to not allow being overwritten?

[Charlie Veniot]

Trying to achieve a robust architecture for a farm of node.js TiddlyWikis 
that together form a distributed database, with end-user level (and 
private) TiddlyWikis that have certain types of tiddlers that are 
automagically shared (and the rest private), and system-level TiddlyWikis 
that tie all of the architecture together along with user-interface stuff, 
etc. etc. etc.

Sure, not very likely end-user folk could muck things up, but a robust 
system really should never allow an end-user to break their TiddlyWiki (in 
this farm idea of mine) by somehow replacing any key component tiddler.

No worries.  I'll train my thoughts on obfuscation, risk-mitigation 
design/strategies, and automated monitoring/repairing processes.

All part of a big idea that ties together, in part:

   - A brewing idea: TiddlyWiki on node.js: check for changes 
   
   - More playing around with TiddlyWiki on node.js: the makings of a 
   distributed database 
   

On Sunday, September 5, 2021 at 8:18:19 PM UTC-3 PMario wrote:

> On Sunday, September 5, 2021 at 8:36:26 PM UTC+2 cj.v...@gmail.com wrote:
> ...
>
>> Is there an easy way to protect such a tiddler?
>>
>
> No. In TW you can overwrite every core tiddler if you like. So there is no 
> way to write-protect a tiddler. 
> What do you want to achieve?
> -m
>  
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/c43f9b8f-a004-41a2-8dd9-c222426f9499n%40googlegroups.com.

[tw5] Re: Can a tiddler be setup to not allow being overwritten?

[PMario]

On Sunday, September 5, 2021 at 8:36:26 PM UTC+2 cj.v...@gmail.com wrote:
...

> Is there an easy way to protect such a tiddler?
>

No. In TW you can overwrite every core tiddler if you like. So there is no 
way to write-protect a tiddler. 
What do you want to achieve?
-m
 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/b7caa9e5-631b-4533-8213-e4557d00beccn%40googlegroups.com.

[tw5] Can a tiddler be setup to not allow being overwritten?

[Charlie Veniot]

Say I have a tiddler that must not be overwritten by things such as:

   - an attempt to save a new tiddler with the same name
   - an import of a tiddler with the same name

i.e. a critical tiddler, one which if overwritten, things will get 
completely screwed up.

Is there an easy way to protect such a tiddler?

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/8468940d-541f-482a-a964-09f8299bddffn%40googlegroups.com.