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

[Charlie Veniot]

Just thinking out loud...

Step 1 to safe-keep important tiddlers: add a little bit of custom code to 
$/core/ui/ImportListing

(Well, I am pondering over what kind of trouble I might get myself into...)

If a tiddler being imported already exists and the already existing one has 
a certain tag, or a certain field, or belongs in a particular list of 
tiddlers somewhere, then:

Disable the select checkbox, and make it unchecked.  Display with the 
tiddler title a message along the lines of "this is a critical tiddler, and 
can only be replaced ".

Something like that.

Step 2: upon press of the delete button on one of these important tiddlers, 
popup a message along the lines of "this is a critical tiddler, and can 
only be deleted ".

Step 3: upon creation of a new tiddler, if the name is edited and set to 
the same name as some already existing tiddler that is one of these 
important tiddlers, then disable the save button and show somewhere a 
message along the lines of "this tiddler already exists and is a critical 
tiddler, and can only be replaced ".

And if I'm thinking about all of this, it is to give time for this sponge 
of mine to conceive "TW integrity" constraints, like database constraints, 
particularly in mind: preventing the deletion of a parent tiddler when 
there are child tiddler dependencies on that parent tiddler.

Something like that.  The wheels are spinning ...





On Wednesday, September 8, 2021 at 7:18:31 AM UTC-3 jeremy...@gmail.com 
wrote:

> Tthis is one of those reasonable sounding features that has a surprising 
> degree of inwardness when one looks into it. Implementing true read-only 
> tiddlers would have a substantial impact on the architecture of TiddlyWiki:
>
> * At the moment, write operations cannot fail, and so there is no error 
> handling in wikitext. If we introduce operations that can fail it seems 
> likely that we'd also have to incorporate error handling features, which 
> would considerably complicate even simple operations
> * Performing the access control lookups would have an impact on 
> performance. The core is architected so that lookup operations on the 
> tiddler store are as fast as possible (a single JS object lookup), and so 
> adding even a little bit more logic will end up multiplying the overall 
> execution time of the store component many times over
>
> So, it was an explicit early design decision that operations on the 
> tiddler store cannot fail. Note that client-server configurations have much 
> more scope to block tiddler modifications being synced in one direction or 
> the other.
>
> Best wishes
>
> Jeremy
>
> On Tuesday, September 7, 2021 at 1:09:01 AM UTC+1 cj.v...@gmail.com wrote:
>
>> Just to re-iterate, there are several ways an important tiddler can be 
>> unintentionally fricasseed.
>>
>> The most likely from a brain-fart moment, examples off the top o' me 
>> noggin':
>>
>>- delete button
>>- drag and drop a crap version that overwrites the good version
>>- bad set-field (or other action widget) that deletes a tiddler, or 
>>completely/partially overwrites the tiddler
>>
>> I'm sure there are other Darwin Award moments, like creating and saving a 
>> new tiddler with the name of an already existing tiddler, and being just 
>> plain old too numb-in-the-moment-deer-in-the-headlights to really clue into 
>> the pending "this is going to leave a scar" moment.
>>
>> Just when one thinks one can trust oneself to not pull an award-winning 
>> dumb move, the IQ-stealing fairy is waiting just around the corner for a 
>> clobbering.
>>
>>
>>
>> On Monday, September 6, 2021 at 8:50:16 PM UTC-3 TW Tones wrote:
>>
>>> On Talk.tiddlywiki.com I would mention Mario and Charlie here. 
>>>
>>> Mario I would like to support part of what Charlie seems to be concerned 
>>> with. I have a few wikis where I have delete inhibit on selected tiddlers, 
>>> typically the master tiddler that is a compound tiddler, meaning it has 
>>> many subtiddlers. Deleting that would result in loss. I have the real 
>>> delete button behind more, so I can get to it. I also have edit inhibit 
>>> because I rarely change the master tiddler but want to edit the 
>>> subtiddlers. A conditional edit button simply helps stop me clicking on the 
>>> wrong edit button. All this can be circumvented, but it helps improve the 
>>> user Interface by avoiding the display of buttons that are not relevant and 
>>> could initiate actions that cause a waste of time if not damage.
>>>
>>> Tones
>>>
>>>
>>> On Monday, 6 September 2021 at 19:07:42 UTC+10 PMario wrote:
>>>
 On Monday, September 6, 2021 at 3:01:25 AM UTC+2 cj.v...@gmail.com 
 wrote:

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

 IMO obfuscation is wasting time, other than removing the buttons, that 
 are not needed. Which I would define as "modifying the UI according to the 

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

[Jeremy Ruston]

Tthis is one of those reasonable sounding features that has a surprising 
degree of inwardness when one looks into it. Implementing true read-only 
tiddlers would have a substantial impact on the architecture of TiddlyWiki:

* At the moment, write operations cannot fail, and so there is no error 
handling in wikitext. If we introduce operations that can fail it seems 
likely that we'd also have to incorporate error handling features, which 
would considerably complicate even simple operations
* Performing the access control lookups would have an impact on 
performance. The core is architected so that lookup operations on the 
tiddler store are as fast as possible (a single JS object lookup), and so 
adding even a little bit more logic will end up multiplying the overall 
execution time of the store component many times over

So, it was an explicit early design decision that operations on the tiddler 
store cannot fail. Note that client-server configurations have much more 
scope to block tiddler modifications being synced in one direction or the 
other.

Best wishes

Jeremy

On Tuesday, September 7, 2021 at 1:09:01 AM UTC+1 cj.v...@gmail.com wrote:

> Just to re-iterate, there are several ways an important tiddler can be 
> unintentionally fricasseed.
>
> The most likely from a brain-fart moment, examples off the top o' me 
> noggin':
>
>- delete button
>- drag and drop a crap version that overwrites the good version
>- bad set-field (or other action widget) that deletes a tiddler, or 
>completely/partially overwrites the tiddler
>
> I'm sure there are other Darwin Award moments, like creating and saving a 
> new tiddler with the name of an already existing tiddler, and being just 
> plain old too numb-in-the-moment-deer-in-the-headlights to really clue into 
> the pending "this is going to leave a scar" moment.
>
> Just when one thinks one can trust oneself to not pull an award-winning 
> dumb move, the IQ-stealing fairy is waiting just around the corner for a 
> clobbering.
>
>
>
> On Monday, September 6, 2021 at 8:50:16 PM UTC-3 TW Tones wrote:
>
>> On Talk.tiddlywiki.com I would mention Mario and Charlie here. 
>>
>> Mario I would like to support part of what Charlie seems to be concerned 
>> with. I have a few wikis where I have delete inhibit on selected tiddlers, 
>> typically the master tiddler that is a compound tiddler, meaning it has 
>> many subtiddlers. Deleting that would result in loss. I have the real 
>> delete button behind more, so I can get to it. I also have edit inhibit 
>> because I rarely change the master tiddler but want to edit the 
>> subtiddlers. A conditional edit button simply helps stop me clicking on the 
>> wrong edit button. All this can be circumvented, but it helps improve the 
>> user Interface by avoiding the display of buttons that are not relevant and 
>> could initiate actions that cause a waste of time if not damage.
>>
>> Tones
>>
>>
>> On Monday, 6 September 2021 at 19:07:42 UTC+10 PMario wrote:
>>
>>> On Monday, September 6, 2021 at 3:01:25 AM UTC+2 cj.v...@gmail.com 
>>> wrote:
>>>
>>> No worries.  I'll train my thoughts on obfuscation, risk-mitigation 
 design/strategies, and automated monitoring/repairing processes.

>>>
>>> IMO obfuscation is wasting time, other than removing the buttons, that 
>>> are not needed. Which I would define as "modifying the UI according to the 
>>> usecase" ;)
>>>
>>> With nodejs you should be able to establish a "batch process" that runs 
>>> once a day and checks, if some important shadow tiddlers have been 
>>> overwritten. I would consider this as "Plan B".
>>>
>>> Plan A - IMO the easiest way would be to trust your users and tell them 
>>> what's going on, and what's important. Having Plan B will then only be 
>>> needed if someone changes something by accident. 
>>>
>>> just a thought
>>> mario
>>>
>>>

-- 
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/c73de05a-18c1-4ddb-a5a9-b4548db90ca9n%40googlegroups.com.

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

[Charlie Veniot]

Just to re-iterate, there are several ways an important tiddler can be 
unintentionally fricasseed.

The most likely from a brain-fart moment, examples off the top o' me 
noggin':

   - delete button
   - drag and drop a crap version that overwrites the good version
   - bad set-field (or other action widget) that deletes a tiddler, or 
   completely/partially overwrites the tiddler

I'm sure there are other Darwin Award moments, like creating and saving a 
new tiddler with the name of an already existing tiddler, and being just 
plain old too numb-in-the-moment-deer-in-the-headlights to really clue into 
the pending "this is going to leave a scar" moment.

Just when one thinks one can trust oneself to not pull an award-winning 
dumb move, the IQ-stealing fairy is waiting just around the corner for a 
clobbering.



On Monday, September 6, 2021 at 8:50:16 PM UTC-3 TW Tones wrote:

> On Talk.tiddlywiki.com I would mention Mario and Charlie here. 
>
> Mario I would like to support part of what Charlie seems to be concerned 
> with. I have a few wikis where I have delete inhibit on selected tiddlers, 
> typically the master tiddler that is a compound tiddler, meaning it has 
> many subtiddlers. Deleting that would result in loss. I have the real 
> delete button behind more, so I can get to it. I also have edit inhibit 
> because I rarely change the master tiddler but want to edit the 
> subtiddlers. A conditional edit button simply helps stop me clicking on the 
> wrong edit button. All this can be circumvented, but it helps improve the 
> user Interface by avoiding the display of buttons that are not relevant and 
> could initiate actions that cause a waste of time if not damage.
>
> Tones
>
>
> On Monday, 6 September 2021 at 19:07:42 UTC+10 PMario wrote:
>
>> On Monday, September 6, 2021 at 3:01:25 AM UTC+2 cj.v...@gmail.com wrote:
>>
>> No worries.  I'll train my thoughts on obfuscation, risk-mitigation 
>>> design/strategies, and automated monitoring/repairing processes.
>>>
>>
>> IMO obfuscation is wasting time, other than removing the buttons, that 
>> are not needed. Which I would define as "modifying the UI according to the 
>> usecase" ;)
>>
>> With nodejs you should be able to establish a "batch process" that runs 
>> once a day and checks, if some important shadow tiddlers have been 
>> overwritten. I would consider this as "Plan B".
>>
>> Plan A - IMO the easiest way would be to trust your users and tell them 
>> what's going on, and what's important. Having Plan B will then only be 
>> needed if someone changes something by accident. 
>>
>> just a thought
>> mario
>>
>>

-- 
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/6765ea61-93ac-440f-b0df-3acf2c37f44bn%40googlegroups.com.

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

[TW Tones]

On Talk.tiddlywiki.com I would mention Mario and Charlie here. 

Mario I would like to support part of what Charlie seems to be concerned 
with. I have a few wikis where I have delete inhibit on selected tiddlers, 
typically the master tiddler that is a compound tiddler, meaning it has 
many subtiddlers. Deleting that would result in loss. I have the real 
delete button behind more, so I can get to it. I also have edit inhibit 
because I rarely change the master tiddler but want to edit the 
subtiddlers. A conditional edit button simply helps stop me clicking on the 
wrong edit button. All this can be circumvented, but it helps improve the 
user Interface by avoiding the display of buttons that are not relevant and 
could initiate actions that cause a waste of time if not damage.

Tones


On Monday, 6 September 2021 at 19:07:42 UTC+10 PMario wrote:

> On Monday, September 6, 2021 at 3:01:25 AM UTC+2 cj.v...@gmail.com wrote:
>
> No worries.  I'll train my thoughts on obfuscation, risk-mitigation 
>> design/strategies, and automated monitoring/repairing processes.
>>
>
> IMO obfuscation is wasting time, other than removing the buttons, that are 
> not needed. Which I would define as "modifying the UI according to the 
> usecase" ;)
>
> With nodejs you should be able to establish a "batch process" that runs 
> once a day and checks, if some important shadow tiddlers have been 
> overwritten. I would consider this as "Plan B".
>
> Plan A - IMO the easiest way would be to trust your users and tell them 
> what's going on, and what's important. Having Plan B will then only be 
> needed if someone changes something by accident. 
>
> just a thought
> mario
>
>

-- 
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/91044a61-12d3-4822-b06a-777d2dfbcdeen%40googlegroups.com.

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

[CJ Veniot]

What I have in mind is pretty simple, and it is about resolving issues that
completely break TiddlyWiki or break an application built upon TiddlyWiki
in a node.js farm of TiddlyWikis.

On Mon, Sep 6, 2021 at 3:57 PM Hans Wobbe  wrote:

> Charlie:
>
> Perhaps some of the protection you are looking for can be had via the
> frequent saves of a tiddler file to Dropbox?
> Unless things have changed since I last used it, that would provide a
> rolling 30 day cache that could be used to recover losses.
>
> Cheers,
> Hans
>
>
> On Monday, September 6, 2021 at 11:24:00 AM UTC-4 cj.v...@gmail.com wrote:
>
>> Well, by obfuscation, I see that as a catch-all word to also mean
>> abstraction, encapsulation, and whatever other little design thingies so
>> that the end result doesn't look anything like TiddlyWiki any more.
>>
>> So a user will have to work very hard to get into trouble.
>>
>> Your Plan B is my Plan A, and your Plan A is my plan Z.  In my mind, folk
>> who are busy with their missions don't need to be distracted by technical
>> stuff needed to be kept in mind.  The best kind of software is the kind
>> that doesn't need any user guide other than, maybe, something concise that
>> lets them know how the software supports them, their goals, their
>> processes.  I prefer that users trust that software they work with is
>> robust/resilient/etc. and doesn't ever waste their time by allowing
>> something to happen that can waste their time.  Well, within reason.  That
>> find balance of cost/benefit.
>>
>> But I do suffer easily from both sensory and cognitive overload, and so
>> heavily do these influence my design philosophies.
>>
>>
>>
>>
>> On Monday, September 6, 2021 at 6:07:42 AM UTC-3 PMario wrote:
>>
>>> On Monday, September 6, 2021 at 3:01:25 AM UTC+2 cj.v...@gmail.com
>>> wrote:
>>>
>>> No worries.  I'll train my thoughts on obfuscation, risk-mitigation
 design/strategies, and automated monitoring/repairing processes.

>>>
>>> IMO obfuscation is wasting time, other than removing the buttons, that
>>> are not needed. Which I would define as "modifying the UI according to the
>>> usecase" ;)
>>>
>>> With nodejs you should be able to establish a "batch process" that runs
>>> once a day and checks, if some important shadow tiddlers have been
>>> overwritten. I would consider this as "Plan B".
>>>
>>> Plan A - IMO the easiest way would be to trust your users and tell them
>>> what's going on, and what's important. Having Plan B will then only be
>>> needed if someone changes something by accident.
>>>
>>> just a thought
>>> mario
>>>
>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "TiddlyWiki" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/tiddlywiki/3mowY9WMyhU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> tiddlywiki+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tiddlywiki/32d6206c-085b-4f5a-a0ea-1e0269e9eda9n%40googlegroups.com
> 
> .
>

-- 
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/CAMu8EfMvRkMCCwb51PoVqjkFe7accBN_Ud_2%3DXkRf%2BLk12jjxA%40mail.gmail.com.

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

[Hans Wobbe]

Charlie:

Perhaps some of the protection you are looking for can be had via the 
frequent saves of a tiddler file to Dropbox?
Unless things have changed since I last used it, that would provide a 
rolling 30 day cache that could be used to recover losses.

Cheers,
Hans


On Monday, September 6, 2021 at 11:24:00 AM UTC-4 cj.v...@gmail.com wrote:

> Well, by obfuscation, I see that as a catch-all word to also mean 
> abstraction, encapsulation, and whatever other little design thingies so 
> that the end result doesn't look anything like TiddlyWiki any more.
>
> So a user will have to work very hard to get into trouble.
>
> Your Plan B is my Plan A, and your Plan A is my plan Z.  In my mind, folk 
> who are busy with their missions don't need to be distracted by technical 
> stuff needed to be kept in mind.  The best kind of software is the kind 
> that doesn't need any user guide other than, maybe, something concise that 
> lets them know how the software supports them, their goals, their 
> processes.  I prefer that users trust that software they work with is 
> robust/resilient/etc. and doesn't ever waste their time by allowing 
> something to happen that can waste their time.  Well, within reason.  That 
> find balance of cost/benefit.
>
> But I do suffer easily from both sensory and cognitive overload, and so 
> heavily do these influence my design philosophies.
>
>
>
>
> On Monday, September 6, 2021 at 6:07:42 AM UTC-3 PMario wrote:
>
>> On Monday, September 6, 2021 at 3:01:25 AM UTC+2 cj.v...@gmail.com wrote:
>>
>> No worries.  I'll train my thoughts on obfuscation, risk-mitigation 
>>> design/strategies, and automated monitoring/repairing processes.
>>>
>>
>> IMO obfuscation is wasting time, other than removing the buttons, that 
>> are not needed. Which I would define as "modifying the UI according to the 
>> usecase" ;)
>>
>> With nodejs you should be able to establish a "batch process" that runs 
>> once a day and checks, if some important shadow tiddlers have been 
>> overwritten. I would consider this as "Plan B".
>>
>> Plan A - IMO the easiest way would be to trust your users and tell them 
>> what's going on, and what's important. Having Plan B will then only be 
>> needed if someone changes something by accident. 
>>
>> just a thought
>> mario
>>
>>

-- 
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/32d6206c-085b-4f5a-a0ea-1e0269e9eda9n%40googlegroups.com.

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

[Charlie Veniot]

Well, by obfuscation, I see that as a catch-all word to also mean 
abstraction, encapsulation, and whatever other little design thingies so 
that the end result doesn't look anything like TiddlyWiki any more.

So a user will have to work very hard to get into trouble.

Your Plan B is my Plan A, and your Plan A is my plan Z.  In my mind, folk 
who are busy with their missions don't need to be distracted by technical 
stuff needed to be kept in mind.  The best kind of software is the kind 
that doesn't need any user guide other than, maybe, something concise that 
lets them know how the software supports them, their goals, their 
processes.  I prefer that users trust that software they work with is 
robust/resilient/etc. and doesn't ever waste their time by allowing 
something to happen that can waste their time.  Well, within reason.  That 
find balance of cost/benefit.

But I do suffer easily from both sensory and cognitive overload, and so 
heavily do these influence my design philosophies.




On Monday, September 6, 2021 at 6:07:42 AM UTC-3 PMario wrote:

> On Monday, September 6, 2021 at 3:01:25 AM UTC+2 cj.v...@gmail.com wrote:
>
> No worries.  I'll train my thoughts on obfuscation, risk-mitigation 
>> design/strategies, and automated monitoring/repairing processes.
>>
>
> IMO obfuscation is wasting time, other than removing the buttons, that are 
> not needed. Which I would define as "modifying the UI according to the 
> usecase" ;)
>
> With nodejs you should be able to establish a "batch process" that runs 
> once a day and checks, if some important shadow tiddlers have been 
> overwritten. I would consider this as "Plan B".
>
> Plan A - IMO the easiest way would be to trust your users and tell them 
> what's going on, and what's important. Having Plan B will then only be 
> needed if someone changes something by accident. 
>
> just a thought
> mario
>
>

-- 
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/3527a15e-a734-444d-8fa1-c141763914cen%40googlegroups.com.

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

[Charlie Veniot]

Oh, don't pursue that for my sake.  I've got something in mind already that 
I want to try out.

On Monday, September 6, 2021 at 3:53:44 AM UTC-3 TW Tones wrote:

> Charlie,
>
> *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.*
>
> But in my earlier reply, I think we can solve this issue by moving the 
> "readonly" tiddlers to a plugin where they become shadow tiddlers. 
> Effectively thus protected tiddlers, Unless the plugin is deleted they will 
> always be there "in the shadows", it would then be simple to detect any 
> edited tiddlers and delete the update reverting to the shadow. Keep in mind 
> the shadow tiddlers can be any name not just system tiddlers.
>
> I can pursue this for you if you want?
>
> I would make;
>
>- An easy way to move a selected tiddler into the safety of a plugin, 
>making it a "protected tiddler".
>- Provide away to detect edited "protected tiddlers" and restore them 
>automatically.
>
> Regards
> Tones
>
> On Monday, 6 September 2021 at 15:54:13 UTC+10 cj.v...@gmail.com wrote:
>
>> 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 

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

[PMario]

On Monday, September 6, 2021 at 3:01:25 AM UTC+2 cj.v...@gmail.com wrote:

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

IMO obfuscation is wasting time, other than removing the buttons, that are 
not needed. Which I would define as "modifying the UI according to the 
usecase" ;)

With nodejs you should be able to establish a "batch process" that runs 
once a day and checks, if some important shadow tiddlers have been 
overwritten. I would consider this as "Plan B".

Plan A - IMO the easiest way would be to trust your users and tell them 
what's going on, and what's important. Having Plan B will then only be 
needed if someone changes something by accident. 

just a thought
mario

-- 
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/d93d0147-8828-4eda-a1a0-c59527a1855en%40googlegroups.com.

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

[TW Tones]

Charlie,

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

But in my earlier reply, I think we can solve this issue by moving the 
"readonly" tiddlers to a plugin where they become shadow tiddlers. 
Effectively thus protected tiddlers, Unless the plugin is deleted they will 
always be there "in the shadows", it would then be simple to detect any 
edited tiddlers and delete the update reverting to the shadow. Keep in mind 
the shadow tiddlers can be any name not just system tiddlers.

I can pursue this for you if you want?

I would make;

   - An easy way to move a selected tiddler into the safety of a plugin, 
   making it a "protected tiddler".
   - Provide away to detect edited "protected tiddlers" and restore them 
   automatically.

Regards
Tones

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

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

[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: 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: 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.