Confirmation

[twMat]

Problem
"Did the fetcher receive my messages? ...maybe something is wrong with my TW or settings? ...and there's a load of old messages I've (hopefully) sent, stacking up - can I delete them?"

Proposal
Confirmations - optional/voluntary on both publisher and fetcher side - that the message has been fetched. Thus the confirmation requesting publisher can fetch this confirmation (assuming the conditions are right).

Strategy
Concerned tiddlers have an optional field fetchconfirmation : requested. I'm uncertain at what point this is best added; e.g when tagging with an (intended) fetcher name or upon bundling.

When un-bundling, this field value is, if permitted by fetcher, changed into fetchconfirmation : <usernameOfPublisher>. (or perhaps the whole field is replaced with e.g field fetchedfrom :...).

Possibly the confirmation is also added to the fetchers copy of the publishers twCard, building up an accumulated list of confirmations. (See more below)

(My original thought was to create a whole new "confirmation tiddler" for each confirmation but this seems overkill and would litter the TW. the confirmation is also meta-data IMO so it belongs to a tiddler.)

Mutual voluntary...ness...
Publisher side: Tiddlers that the publisher would like fetchconfirmation requests on have a fetchconfirmation : unconfirmed field. For starters this can be added manually but an idea is to have it automatically added either as the tiddler is tagged (or otherwise addressed) with a fetchers name, e.g *inmysocks or, perhaps, via some central list in the publishers tw where he can 'batch befield' tiddlers with this.

Fetcher side; the //un-bundling mechanism// detects this field and, in the listing of "to-be-unbundled" tiddlers, displays checkboxes next to each tiddler that requests confirmation. By default it is checked, indicating that the field - on unbundling - will get value usernameOfPublisher. Manually unchecking the checkbox prevents adding this value.

Tiddlers to be unbundled	Confirmation
Foo bar
Your house is on fire	☑
I had pizza for dinner

Obviously a field can be manually changed later anyway.

The reason it is better with fetchconfirmation : usernameOfPublisher than : usernameOfFetcher or : confirmed is because there may be multiple tiddlers with identical titles from different publishers. This way there is more chance that the publisher will get correct confirmation note.

If overwriting is prevented - e.g by added timestamps in tiddler title - then I guess fetch : confirmed is more eloquent. (And perhaps changing it to be fetch : <confirmation requested / confirmed>) BUT... (se next paragraph)

Checking confirmation status
To know if a tiddler has been fetched, the publisher would probably himself have to fetch the confirmed tiddler. This (ref to the BUT above) probably requires that the title has remained the same. At the same time, the original should probably not be overwritten (maybe the fetcher has made a content change, such as added his own notes to a fetched tiddler).

An idea might be to use the twCards; On the fetcher side, the confirmation is (in addition to the tiddlers fetchconfirmation field) added to publishers local twCard that the fetcher holds. The publisher thus imports his own twCard to see confirmations for tiddlers. Should probably be an accumulating shadow tiddler.

When the publisher fetches "his own" twCard, this is during the fetching process changed so that the information therein is instead added to the fetchers twCard in the publishers TW. So the publisher peeks in his local copy of the fetchers twCard to get a summary of the confirmations.

In the publishers wiki, there might be a setting (particularly for personal communication) to have a concerned tiddler display perhaps a little yellow dot while unconfirmed and when confirmed, as detected in the twCard, it shows green instead.

[twMat]

@inmysocks - the OP has been severely updated from yesterday.

---

'nuther UI idea:

In the publishers wiki, the tag stating the intended fetcher (e.g inmysocks) is originally in yellow. If a confirmation is fetched, and found to be confirmed, the tag color is changed to green!

[twMat]

Hm, I'm reconsidering strategy - and adding along some important bits, including a system to partially clean up outdated twCards from circulating in the TWederation;

• A tiddler can be addressed to multiple intended fetchers so it should be possible with multiple, fetcher-specific, confirmations.
• A fetcher should not be bothered that merely confirmation status(es) has changed in the original tiddler.
• A fetcher should see neither confirmation requests nor confirmations that don't have to do with himself.

This speaks for separating the confirmation stuff from the tiddler itself.

Confirmations lists
To not use separate tiddlers for each single confirmation or confirmation request, these could be in the form of confirmation lists; the publisher has fetcher twCards that each include a list with the relevant confirmation matters. More on this below.

Fetchers getting confirmation requests
The fetcher obtains a request as part of regular fetching, because the publishers bundling mechanism..:

includes - "bundles along" - the confirmation request list - or -
*reads the confirmation request list, i.e the bundling mechanism looks in this list and applies appropriate confirmation stuff to the *tiddlers that are being fetched/bundled.

Fetcher twCards in publishers TW
The publisher would thus have twCards with the fetchers details. Now, if the publisher does not previously own this fetcher card, it is intially an autogenerated empty card pretty much only having the fetchers username in it. This empty card is bundled along and has itself a confirmation request, but a bit special in that it is a request for the fetchers real twCard. This would in effect be a "cleaning system" in the TWederation to update the twCards!. Otherwise I see a risk in having outdated twCards circulate.

Now, the confirmation list isn't really in the twCard. It is a separate tiddler that perhaps shows up as a tab in the twCard or as a transclusion. This is so that different publishers only have the relevant list concerning the specific publisher himself and the fetcher.

Fetched confirmations replace the status in the fetcher-specific confirmation list held by the publisher. And the information is presented perhaps as suggested in last post; coloring the tag accordingly :-)