Very recently (in the current indefinitely time-boxed sprint) I have decided that messages and challenges (or, as I had less recently as in the sprint just prior to the current sprint - according to the change log of my Git code base it concluded yesterday) no longer have structural relevance. What I mean by this is that there are no components (classes or methods or anything else) that go directly to defining a particular challenge or message component.
It is noted that signals that flow out of initiators and to respondents (deemed challenges) are identical to signals that flow the other way (deemed messages). The difference still does seem to have relevance, however, consensus appears to be settling on the notion that the labels used for the dichotomy can be dropped in favour of the use of initiator signals for challenges and respondent signals for messages. The difference merely being that initiator signals travel from initiator to respondent while respondent signals flow the other way. Being that there is no other great functional difference between these two signals (as was envisaged for several years up to now) the dichotomy no longer applied and was dropped.
Both types of signals are represented by the same signal object, save the only dichotomy now that seems still worthy of modelling: the one between constraints and contexts (nee features - another renaming that occurred about half a year or so ago). Hence, the same type of constraint signal that is sent from initiator to respondent is also sent from respondent to initiator; so for the context signal. Whether from respondent to initiator or the other direction, both types of signals contain indistinguishable information.
Or do they?
I am seriously considering setting a single bit: switched on for a signal sent from an initiator and off for one sent from a respondent. This single bit difference would yield a completely different digest or signature; one could not create an initiator's signal that was sent through a respondent's synapse. Perhaps better yet, the bit is stored in the serialisable deliberation that is generated from a non-serialisable deliberator. The bit is kept in the deliberator so it generates the appropriate signature for the correct receiving direction. The deliberation may not have to record the bit because it would be inferred by the receiver.
This is all quite deliciously speculative...
