Visit https://tiddlywiki.com/empty.html?name=ferret&color=purple and then look at the shadow tiddler: $:/info/url/search.
So the startup actions would split/parse the text of this tiddler and extract the information needed and save it in tiddlers for reference.
This is cleaner in the sense that you do not need to deal with missing tiddlers in the story at all.
Excellent, thanks.
The documentation is here: https://tiddlywiki.com/#InfoMechanism
But I didn’t find it with my intuitive search terms (query, permaview, url)… It’s there under “url” – but quite buried under a gazillion tiddlers with a url field.
(So, this request-for-better-documentation is flagged here for the general vague community of people tracking things that could be documented a bit more explicitly!)
That makes me wonder why there isn’t also a $:/info/url/fragment node. Even if it didn’t dynamically update with permalink/permaview actions, it could be very useful to have the initial value (such as #InfoMechanism) available during startup actions.
Does anyone know, was this an oversight, or was it intentional?
Hi @Scott_Sauyet as you note, the problem is that the current info mechanism only handles static information that doesn’t change after the wiki has loaded.
There are some GitHub tickets with further discussion:
Thank you. I read through all those issues, and the concern was exactly the one I expected.
I wonder if there’s a potential middle-ground of creating a tiddler that is removed once the start-up actions have completed. If one of those actions wants to create a more permanent version of the initial state, it’s free to do so, but otherwise, this is just gone. I have no idea if this is done elsewhere in TiddlyWiki now, creating a transient tiddler, but, as an outsider, I can’t see anything fundamentally wrong with the concept.
One nice point is that with the two equally familiar names of fragment and hash, we could do this with one of them, and reserve the other for potential future use without worrying about backward compatibility – although of course near-aliases have their own problems.
I am not sure that there is an obvious, clean way to remove the tiddler at the end of startup, but I’d be more concerned that it would be confusing for users.
I think the best way forward is to extend the info mechanism to support dynamically changing values, along with a mechanism for triggering action strings when an info value changes.
Jeremy, perhaps the context isn’t entirely clear (on this long thread) – in this kind of case, the tiddlers are designed to be invisible, and so nothing would “disappear” from users’ point of view. Removing them from the story river (after using them to set various field-values) would save a bit of anxiety over whether these distracting but missing and non-displaying titles are visible in the Open tab (for example) or in other plugins that reference the story river (such as quickjump).
I do think the “query” approach is more semantic. Alas, I’ve already built a whole approach (which needs to work at least through the rest of this semester) around user-specific permaviews. Because it’s served up within an iframe users don’t see their individual url values, and I don’t want to encourage users to poke around with easily reconstructing others’ “cookie” values (they’re serving the function of keeping some student info in view, while keeping other student info away from easy discovery).
So, my solution for now involves having calculated permaviews whose hashes hold id/key variables (to determine the content of an iframe, where that url is never seen by the intended LMS visitors). In other words, these users ideally never interact with or even see mention of the titles of the missing tiddlers which are serving this back-end purpose.
Apologies @Springer, my comment to @Scott_Sauyet was referring to an implementation detail about the proposal for adding access to the URL fragment identifier via a $:/info/... tiddler. @Scott_Sauyet had proposed that one of those info tiddlers would disappear after startup.
As I said, this was an attempt at a middle ground. It could also just be labeled:
$:/info/startup/url/fragment
to make it more clear that it’s temporary.
But this would be better.
… Much better.
… Much, much better.
Of course this is me speaking of as a developer who’s used to being able to easily listen to arbitrary events.
Even so, there’s likely some value in keeping the initially loaded fragment available, so that we could offer an equivalent to a “Home” button that returns to the initial state.
@Scott_Sauyet I am not exactly sure why but on this subject an example that comes to mind is $:/temp/volatile/ mentioned in RefreshThrottling or using a namespace. This thread has helped me clarify in my mind a little more on handling different namespaces.
In brief, a startup action can take steps to store whatever it wants from whatever information is available such as the $:/info tiddlers, and store it how it wants.
Namespaces
We can simply adopt a namespace for whatever we want either inside the system name space $:/new or outside #:/new the detail is of course how different parts of tiddlywiki then handle the tiddlers with a given namespace. Areas we may want to alter are;
$:/ to stop this alreadyIn relation to this Topic for example we could develop a namespace for tiddlers that are not visible in the story or standard lists.
In reality there are not many places we need to intervene in TiddlyWiki to get a whole namespace to be developed with different qualities. That is tiddlers with an alternate namespace to be treated differently to others. Existing examples include system/non-system/shadow/temp/state/$:/info etc…
I raise this because not only can we do this quite easily but I foresee being able to make such namespace design a hackable feature of a particular tiddlywiki edition, or perhaps sometime in the future part of the core.
is or all filter operators would be nice.Yes, while $:/temp/volatile is meant for a different purpose than what I suggested here, they are clearly related concepts.
The trouble is that the information is not available right now through the info mechanism (or, as far as I can tell, through any other mechanism unless you write custom JS.) If you visit
https://tiddlywiki.com/#RefreshThrottling
and look at $:/info/url/full, you will find that the fragment identifier is not included. The value will just be “https://tiddlywiki.com/”.
You can contrast this with a url that includes a query. If you visit this:
https://tiddlywiki.com/?RefreshThrottling (note that this has a ? instead of a #)
then $:/info/url/full has the value “https://tiddlywiki.com/?RefreshThrottling” and $:/info/url/search has “?RefreshThrottling”.
There’s no equivalent for the fragment/hash. Currently, you’d have to descend into JavaScript to get access to it. That’s simple enough JS, but I was suggesting that even though TW hijacks the standard browser fragment navigation, we might still want to know the initial value from page load.
In any case, this suggestion was a work-around, avoiding doing some of the harder work that would make this more robust. @jeremyruston seems inclined to do that harder work, so I think this suggestion is moot.
As to your more general point about namespaces, I’m surprised to hear that it would be relatively simple to add new ones. I would have expected that it would be a fair bit of work, that the current public/system/shadow trio was likely embedded deeply in the code. But I haven’t looked into it and have no basis for that assumption.
If you’re right, and that could become a hackable mechanism, it’s interesting, and I could imagine that one day I might want it, but I can’t think of anything I’ve done so far that really would have benefitted from it. I’d be interested to hear more specifics about how you might see this being used.
Yes, I had not noticed that until you pointed it out. You could say $:/info/url/full returns a lie, it is not “full”.
? and not using the # (sorry if I missed a prior answer of yours)
? clash with Timimi saving# values were available in the full uri and/or its own “list”I POSTED in a new thread on namespaces Lets discuss new and or custom namespaces
Sure. But the current rationale for this is fairly clear. Tiddlywiki appropriates the usual hash navigation in the browser to load tiddlers into the story river. So the initial hash value has limited usage. But there are some possible uses, and it might be especially relevant at load time, or, as I mentioned before, as an alternative “home” link.
Two reasons I can think of:
The query/search parameters are meant for the server-side, whereas the fragment/hash one is meant for the client-side. Mixing them up is crossing the streams. They provoke very different behaviors in the browser. Changing the query parameters by default will call back to the server for what could theoretically be entirely different content. Changing the fragment does not refresh the page, although the client side can do what it likes in that case.
Using the fragment should work well with the Permalink/Permaview mechanisms, which give you a shareable URL using the fragment.
Did you see my reference to https://namespaces.tiddlyhost.com/ ?, which does;
make missing tiddlers display:none or visibility: invisible?
In a systematic way. Althgough perhaps not so simply, it is packaged namespaces.json (26.0 KB) modifies some core tiddlers.
Partially, but not fully, I think. The various backends for a TiddlyWiki could easily use the query parameters to do specific differentiation in the content supplied. They cannot use the fragment, which is not sent back to the server (or at least didn’t used to be) but is reserved for the client. Reserving the query for the client mostly prohibits such differentiation.
Here’s one possibility: @Springer is using TiddlyWiki in the classroom, using a shared wiki for a class. She may have difficulty adding private commentary to students’ work… because this is a shared wiki, and should probably stay that way. And she’d better not put grades or other more private information into the wiki without possibly running afoul of the law. But what if we could offer her a back-end which allows for both this shared uri:
http://myschool.example.com/philosophy/ethic101/2023-spring/
, which contains only the shared information, but also this
http://myschool.example.com/philosophy/ethic101/2023-spring/?student=123456
, which includes all the common information as well as the more private information.
To log into the latter you have to have the password matching that student id, as recognized by the school.
This should be a relatively straightforward extension to the Node back end or a simple alternative to it. The thing is, if we coopt the search string for the client side, then this is no longer really possible, because perhaps ?student=123456 means something entirely different in the client. I understand that there are alternative ways for the server to differentiate and validate users; the trouble is that this is a tool meant for that, and claiming it for the client removes to capability to do that on the server.
The fragment, meanwhile, is designed explicitly to identify a portion of the document/wiki. While it’s traditionally been used to match an HTML id in the document, TW’s use of it to mark and/or load some subset of the tiddlers is still within the spirit of its design.
I did and have been reading it, although so far I have nothing to add. I’m really hoping to see some more specific practical applications of the ideas, as I haven’t yet figured out how this might be useful.
As mentioned previously, I agree it would be helpful if the fragment(s) or tiddlernames given in the URI could be accessed on the server and in the single file wiki.
It can already satisfy the following; but of course this discussion has moved on from there.
For example, try it, tiddlers with the _ prefix, follow this link, the tiddler exists but cannot be seen anywhere without work, https://namespaces.tiddlyhost.com/#_Semi-Secret%20content (or paste in a browser)
_Semi-Secret content tiddlerI agree there is value in using a server implementation for some backend details or secrets, but I would urge you to keep an open mind, and I always maintain a single file tiddlywiki perspective, I am not sure your statements about the difference between front end and back end, all hold true. But perhaps this is not the place to discuss this.
For example yet another approach
Encrypted tiddlers
I have in the past used the tiddler encryption plugin to hide a users profile and secret, one could pass the user name in the URI and then use an encryption key to expose the secret.
But we are again straying from the OT.
Please note that one thing that drove me to the current permaview-iframe approach is that I do NOT have to create, disseminate, and manage separate encryption keys for each student (egads, there are dozens… and they would have to be separate, since one central point is to give students a reasonable sense of privacy vis-a-vis their peers, when it comes to things like exam grades).
Instead, the “virtual tiddlers” in each student’s permalink hash include two different numeric strings plus a text string (all pulled from the LMS with help of generico plugin), and I create a key (for use in list fields) based on a mathematical function that leverages these student-specific strings.
Putting this non-recognizable key value into list fields, etc., allows “back-door” access via filters (and these filters only produce results when the right permalink-tiddlers-at-startup conditions are met — again unless someone with TW savvy does some set-field operations, which means hacking past the read-only css).
Since students don’t even see the url of their iframes (not without an enormous deal of hacking the LMS), they don’t easily know what their starting metadata points are… And, since they don’t know the “secret sauce” that converts their unique combination of LMS user-metadata into a keyfield, I believe the privacy is reasonable. (That is, a user might be able to deduce what their OWN key value is and see where it appears within JSONs in source code, they can’t easily reverse-engineer WHY their key value is what it is, nor how to crab-walk from appearances of their own key value string (in source code) to connect others’ online results to any meaningful student-specific string found on the university servers. 
)
Good enough for banking security? No. Then again, my office windows, where grades appear in paper form, aren’t secured like the windows of banks either.
The only way I know to make that secure would involve a different form of encrypted tiddler than is available now. The students would have to generate their own public-private keys, distribute the public one to the professor or somehow to the back-end system, and make sure that they keep track of their private keys. Then the back-end could encrypt the tiddlers with their public keys so that the students could decrypt them at the appropriate time. This is all well-trodden ground, but it more work to administer, bloats the shared wiki with lots of data irrelevant to the user, and has a serious issue if it’s used like the current encryption, where you would need to re-encrypt the tiddler before saving your changes or risk others seeing it.
My suggestion is simpler for the students, for the professor, and probably much simpler to code as well. It does not have to use the query parameters; that is only one possible scheme. But the main point was that something like this would require that the client not try to repurpose the query string. By doing so, you’re making undue assumptions about what the back-end might want to do.
As we’ve discussed off-line, I think there are probably decent ways to do this without Rube Goldberg tooling, and at some time, I would like to look into them. But I really doubt it will be before next semester starts.
Long ago. I’m sorry, I started us down a path entirely irrelevant to the original question.
In a sense, yes. But also — as @TW_Tones frequently points out — many posts start with a surface question (“How do I produce a certain behavior? (How can I put missing tiddlers below the radar in read-only mode?)” … but the thread needs to turn toward a deeper question (“How best can TW meet this need?” How best to reveal different tiddler/template subsets to distinct viewers based on their different iframe URLs?").
Encryption-oriented solutions do count as a change of subject (for this thread’s purposes), but everything about hashes vs query-strings, and how these might best be handled so that end-users (with their iframes) get a consistent tailored experience (including intuitive in-frame refresh handling if possible) is all on target.
In all of the methods discussed here @Scott_Sauyet and @Springer there are dozens of different branches and methods we can deploy. For each approach a tweak or mechanism can be found, whenever an objection can be raised. I could contest some of the implications in both your replies, but we are now so “deep in the weeds” I doubt it is of too much value responding.