#1. Filtering on link type is possible for action codes link links(), linkedTo(), linkedFrom(). The latter pair are simple boolean-resolved queries asking if the currently assessed note is linked to/from other notes as defined by the link direction and (optional link type filter). The best think is to try the code and ask if you get stuck. Your questions are more open-ended than you perhaps intended. I suspect this comes from recently using tools optimised for a small range of functions some of which I’m sure may not be possible—at least in the same fashion—within Tinderbox. Then again trying to understand this app from the perspective of some other app is not helpful to learning as it starts from a set of false assumptions (i.e. how the other app works) as to how Tinderbox is designed.
#2. User attributes are a very powerful and a great way of abstracting metadata whether from the noter’s $Text or just as further annotation. That said, some people perfectly happily write title+text notes and touch hardly any of the more powerful features. Tinderbox doesn’t try to set you on a particular path. this is why I think some find it hard to to get into as they are some used to the app telling them what that can (or as often can’t do. Getting back into the habit of thinking about what you want to do is useful. Of course, if that is simply trying to copy the limited behaviour in some other app then that’s not really engaging with the problem as one is still entombed is a set of workflow assumptions which are not longer pertinent. You will find those who get the most out of the app look at the nature of the task rather than the exact detail as to how it is achieved.
#3.Hyperbolic view shows all notes linked directly of indirectly from the current selection (at time of view selection - the note with a read border. Clicking another note selects it in the text pane and rotates the view (on the underlying spherical plane) so as to centre the selected note. Double-clicking a note makes that the centre node (terminology not established?) for the view.
Put another way, two notes that cannot be reached by traversing links (which excludes the document outline’s hierarchy) cannot appear on the same map. In a large document it is perfectly possible to have discrete networks of linked notes in the document with no common links—I.e. the two networks cannot be viewed at once as they have no interlinked. IIRC Obsidian shows a database-scoped force directed patters where individual or small clusters are pushed to the edge., which is a similar looking (box-and-line) graph but arrayed for a different purpose. The nature of what the note represents is irrelevant in therms of the view construction which is link centric.
I’ve added some more data to my test doc (see new prototype example3.tbx (100.1 KB)) Example 4 has no callers in common with other calls, whereas call 1 2 and 3 do share linked callers. This should help you to experiment.
I thoroughly commend @PaulWalters’ recommendation to just try things. Tinderbox is quite happy to make lots of documents. Making a new small doc to test just one small thinking is a really powerful way of moving forward, not least as it makes one figure the inputs/ needed/outputs expected thus refining understanding of the process. The temptation is to make one document and try and both make a clean working doc and lear the app all in the same place. That’s possible but making life harder than it should be.