waleedmebane / allsembly-prototype Goto Github PK

See about_license.md for full rationale.

I will wait a little while to get some feedback. The addition can wait until there are pull requests from other potential contributors.

Draft text:

Linking Exception. As an exception to Section 4 of the LGPL, the copyright holders of this software give you permission to convey a Combined Work under the terms of your choice [the first part of Section 4 without "that... do not restrict modification... and reverse engineering for debugging..."] provided you meet the requirements listed as (a) - (c) under Section 4 and that you convey the Minimum Corrresponding Source [as in 4 (d0)] but without the need to convey the Corresponding Application Code. This exception does not invalidate any other reason why your software might be covered by the LGPL or the GPL; and it does not alter any license term of any work that is part of the Application combined with the Library even if one or more copyright holders of the Library are also incidentally copyright holders of those works. You must still adhere to all of the license terms of any other works you combine or link with the Library.

It is the intention of the copyright holders that the exception given in Section 1 of the LGPL still apply if it otherwise would have applied by your meeting the terms of Section 4 without the above addtional exception.

It is the intention of the copyright holders that they or their agents be permitted to disassemble, decompile, or reverse engineer the Combined Work for the purpose of determining compliance with the license terms but that the terms under which you convey the Combined Work need not be compatible with reverse engineering, as mentioned in Section 4 of the LGPL, or disassembly or decompilation, for any other purpose.

Note: I don't say anything about "static linking" because I don't intend to restrict the means of linking or combining. Licensees can cut and paste if they want. As I understand it, the LGPL is clear even in such a case that if their code does more with "the Library" than call its functions and subclass its classes, then such code would be "based on" "the Library" rather than just based on "the Application" and need to be conveyed as part of "Minimum Corresponding Source". The exception excludes LGPL Section 4(e) (the requirement to provide installation information) because it might be interpretted to require that the user be able to modify the Combined Work (see, e.g., https://www.gnu.org/licenses/gpl-faq.html#RemoteAttestation).

I read about it a few days ago. I have to go back later and check to recall what it is that is being removed and then update this issue.

TODO: in the short term, modify requirements.txt to indicate django<5.0 and test the install.
Eventually, maybe make the project compatible with Django 5+.

This is because of long polling. Apache's default timeout is 300 seconds, after which it kills the django session causing the user to get logged out.

A workaround is to set the timeout to a larger value. For example, set "Timeout 1800" in /etc/apache2/apache2.conf.

This problem occurs in Firefox 115.3.1esr (64-bit) for Windows and 88.0 (64-bit) for Linux, that I've seen.
An error "NS_BINDING_ABORT" appears in the Web Developer Tools "Network" area.
One is not logged out and can go back to the demo page by entering the URL in the location line.

My thought was that such positions are just as likely to be true as false.
However, now I'm pretty sure that is not a realistic model.
I don't think an arbitrary statement is just as likely to be true as false. Probably there are many many more grammatically correct absurd statements than true statements.

I should not assume that a participant is 50% likely to know that a statement they suppose is true actually is true. I don't know anything about the participant's level of knowledge on the subject. I also don't assume that participants are acting in good faith.
So, I have no reason to believe the position. The act of asserting it isn't a piece of evidence. It's probably not good to consider that it will average out to 50% either because some positions have greater strategic importance to the status of conclusions than others, and it leaves the system vulnerable to spamming of absurd positions by bad-faith participants to boost the probability of a conclusion.

So, it seems that I should let such positions default to false (probability 0) until some evidence comes in. Betting counts as a piece of evidence because a participant making a bet is taking a risk. So, that gives an indication of the strength and sincerity of their belief.

I will also have to update the "Walkthrough" section of the User's Guide in the documentation after making the change.

This also suggests that there should be two separate deadlines. One deadline would be for all arguments to be added that will be added during a particular dialogue. After that there should be a period of time during which the participants evaluate existing positions that they haven't had a chance to evaluate so far and make bets if they are interested in doing so. That way there is a better chance for the price of lately added positions to reflect the inputs of many participants instead of just a few.

Currently the code and settings used in the online demo for creating captchas is found in the "demo-settings" branch. Move that to the "main" branch once there is a good way to make it optional.

Additional installation steps are needed to use captchas from the 'demo-settings' branch:

pip3 install 'django-simple-captcha'
sudo apt-get install libz-dev libjpeg-dev libfreetype6-dev python-dev
sudo apt-get install flite

Flite is a voice synthesis package used to provide an audio version of the captcha.

Not working in Firefox 115.3.1esr (64-bit) for Windows and 88.0 (64-bit) for Linux, that I've seen.
The root cause might be the same as in issue #7 .

The problem became obvious after adding the workaround for that issue, but I'm not certain that it was working before. It might have only left the page before, when the logout link was used. Although it worked in some earlier versions that I tested, the root cause might be something to do with the long polling.

The client sometimes requests a new version of the argument graph before it has finished
being drawn. When that happens, some just added nodes appear to the far left of the diagram,
not connected to the rest of the graph, and the probabilities might not have been updated.

The problem is with rypc_server.GraphRequest. It calls draw_graph() directly on a reference to the
ArgumentGraph object from the AllsemblyServer's thread. Instead, it should load its own ArgumentGraph object
from the committed version in the database.

The client call to the API to get the updated graph should return the
graph together with a revision number. Then future calls will
include the last revision number that the client received, and if no new graph is available,
the call can return with XML containing that information. Then,
only in that case, the client-side Javascript will wait and try
again. Ideally, the information will include whether an update
is in progress or whether no update is expected. If a change
had been requested but no update is expected, then the client
can resubmit the change. Additional details such as request
numbers and request receipts can be used to guard the integrity
of the data and robustness of processing. See the heading "Design for Integrity" in the Programmer's Guide of
the documentation for initial thoughts about ensuring that the server records requests accurately and
completely. Additionally, the client should digitally sign requests (to keep it accountable) and the
server should likewise digitally sign receipts.

There is a workaround in commit 5d7725e (in the django-version branch).

The server main loop doesn't exit because it is waiting on activity from its queues.
A fix would be to share the Event object with the server script so that it can wake the server main loop thread.
Make an Event a member of the server_control class.