Bbska is on the go!

bbskaBbska (pronounced as bee-bee-ska, or ba-boo-ska, or ba-boo-ska) is a simple tool for helping you keep your every day data in a babushka-like manner, thus putting data nodes inside other data nodes, which you can put inside other data nodes and so on. As said, bbska is just a simple tool for managing small data chunks, not a database monster, neither a big data client, nor any kind of data store panacea.

You may not use bbska for storing your business data, you may not compute your company’s payroll using bbska and you cannot make scientific research with bbska. But you can use bbska for keeping your phonebook in a tree-like manner, as you can keep your browser bookmarks or your favorite music pieces, you can store and seek your books, your accounts, your friends, your thoughts and keep a simple but helpful to-do list.

You can also map your network nodes using bbska, or store and manage your chess games, as you can access your photos, your documents and your email messages. You may ask if you can keep your guitar lessons using bbska, or seek your car’s services putting records in matryoshka dolls. The answer to this kind of questions is just a few clicks away, all you have to do is to create an account an give bbska a try!



Caching is now on for all kinds of requests, aka privateanonymous and foreign requests. Requests are considered as anonymous when there is no logged-in user in the submitter page. Requests are considered as foreign when a logged-in user requests other users’ (public) information nodes, e.g. if user maria requests the (public) node 3552772 which belongs to user panos, then that request is considered as foreign. As for logged-in users requesting their own information nodes, private cache files will be whipped out every time the user enters update mode (B). A logged-in user may remove all cached data of her own nodes by clicking the [Recache] tab at the right side of the toolbar (A):



When a logged-in user updates her data, then that data may not be exposed to other users, especially when the nodes requested have been cached already, until the user clears her cached data. So, in order to expose updated data, the user must recache her data.


Sometimes sorting “by hand” becomes a very nasty process, especially when there are too many sibling nodes; there comes the _sort_ attribute at rescue. We can supply one (or more) sort tags in order to sort sibling nodes. Nodes with missing sort tags will be displayed first.

One can also use the _tros_ (opposite of _sort_) attribute in order to provide “hidden” sort keys. Hidden keys are used in sorting, but they will not be displayed.

URL parameters and special attributes

There is a number of URL parameters that control program’s behavior. The most important parameter is root, that is the root node’s id, e.g.

will display node 28992 and all of its first level ancestors.

We can specify the favicon with the icon parameter which is the desired favicon’s image URL, e.g.

will display the image as the page favicon.

We can also specify the title of the page, e.g. the browser tab tag for the page, using the title URL parameter, e.g.

We can specify the URL of an image to be used as the favicon when using the node as the root node, just by adding the desired image URL as _icon_ attribute to that node. Likewise we can specify the page title by using the _title_ attribute.

Next comes the explode parameter with no value needed. If the explode parameter exists, then every node will be spread (except neutral and blocked nodes), e.g.

will display node 28992 and all of its ancestors opened down to the lowest level, or until neutral or blocked nodes reached.

We can specify a node as explosive just by adding the _explode_ attribute (with no value). An explosive node will be exploded when used as the root node of the page. In order to prevent various ancestor nodes from recursive explosion, we can add the _neutral_ attribute (no value needed) to those nodes.

One may also use the somehow weird _block_ attribute in order to block data under a node from further loading. This attribute may be proved useful for autonomous nodes’ management in order to avoid loading tons of useless data. However, a blocked node will be loaded normally when used as the root node of the page.

When the key or the value of any attribute is recognized as valid URL, then a link will be provided to the user. If the key or the value is recognized as a valid image URL, then that image will be displayed inside the node. When the key is an image and the value is a URL, then the image will displayed with a discreet shadow and a link will be provided, so the user can click that image an open that link in a new page. When the key or the value is recognized as a valid email address, then a mailto link will be provided.

There is another URL parameter that affects the display format of the information nodes. Every node has an ID, that is a unique number that corresponds to that node. The node’s ID is not displayed by default, but the user may cause nodes’ IDs to be displayed, just by clicking the relevant button in the control panel at the left side of the page. The user can also display the nodes’ IDs by default using the info URL parameter (no value needed), e.g.

will display the node tree under the 28992 node with the IDs displayed by default. The info URL parameter will be passed over pages originated by the new page button which may be used for displaying specific nodes in separate browser tabs.

A useful special attribute is the _chain_ attribute which can be used in order to link irrelevant nodes. To be more specific, we can specify a node ID using the _chain_ attribute in order to provide a link to that node by clicking the chain icon displayed just after the zoom icon. We can also specify URL parameters along with the node ID which will be passed over to the new bbska page, e.g.


One may use the _chain_ attribute in order to provide a link not just to an irrelevant bbska node, but to any web page just by specifying the desired URL as the _chain_ attribute’s value. We can also specify some piece of information to be displayed over that icon, by the means of the _chinfo_ attribute.

The last item to be discussed in the current post is the eco URL parameter which affects search results. As you may know, after searching some item, the target nodes are displayed with all their parent nodes spread, for the nodes’ position to become more apparent in the nodes’ tree and between the sibling nodes also. We can eliminate results to just the target nodes (and their ancestors of course, but not spread) by using the eco URL parameter (no value needed).


After running and testing bbska for about 8 months, time has been reached to enjoy fast and easy to use responsive pages full of information nodes organized in a matryoshka manner, controlled by user friendly and easy to use interface.