1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
|
* The current rules for when an Activity Entered is accepted allow it to
refer to an older activity than the last one. If echoing is disabled,
two Activity Entered could be sent, each pointing at the most recent
Activity Seen, and there would be no proof of the order of the two.
Reordering the two might cause different results though.
This is not only a problem when 2 developers are connected; it also
lets a single developer produce a proof chain that is ambiguous about
what order they entered 2 things.
Fix: Make a Activity Entered have a pointer to the previous Activity
Entered that was accepted, in addition to the existing pointer. Then
when one developer sends two Activity Entered that don't echo, there's
still proof of ordering. When two developers are typing at the same
time, only one of their inputs will be accepted. The client should only
consider an Activity Entered legal if it points to the last Activity
Entered that the client saw.
May as well make Activity Seen have a pointer to the last accepted
Activity Entered as well. This will make it easier when supported
multiple developers, as each time a developer gets an Activity Seen,
they can update their state to use the Activity Entered that it points
to. (Perhaps not needed now that developers see other developer's
Activity Entered.. But, this does let developers know what the current
accepted line is.)
* Client should upload to multiple servers, for redundancy. This way,
if Joey runs a server, and Alice runs a server, the user can start
debug-me and not worry that Joey will connect, do something bad, and have
his server cover it up, because Alice's server will also get the data.
When Bob connects to Alice's server and sends messages to the client,
it should then repeat those same messages to Joey's server (but not back
to Alice's server).
This will use some more bandwidth of course. Inter-server replication
could also be done to avoid using client bandwidth. But then, if the
client only sent to Joey's server and trusted it to replicate to Alice,
Joey could break the replication to cover up his nefarious activities
in the debug-me session.
* When the user presses control-s, before forwarding it to the terminal,
stop accepting any developer input. Control-s again to resume.
(Or, add buttons to the control window to do this.)
* Make control-backslash immediately end the debug-me session.
* Need to spin up a debug-me server and make debug-me use it by default,
not localhost.
* Make debug-me --bundle create a self-contained executable bundle
that can be ran anywhere. Update faq to suggest developers include that
with their software.
|