“The Community” like more than just 5 nerds are talking in this thread
i love u guys
1 Like
I think I’m fine if somebody wants to have the program spit that out in a case like this because (again to call back to Lumi’s points) it’s really not very convincing
like I’d argue having the program do that makes it worse not better at predicting alignment in a case like that shown
3 Likes
that being said I think just writing a rule that says programs can’t present conclusions for you is probably pretty reasonable
2 Likes
so true
easy response to this as a program developer is “this game is X far from mafia and Y far from town” btw which is honestly something people should be doing anyways if they want the tool to not be shit
3 Likes
How many degrees of separation from a conclusion does it need to be? If it spits out a number between 0 and 1, and that represents a probability of a particular outcome, is that “presenting a conclusion” even though there is an albeit trivial interpretation step?
1 Like
I would say that is not presenting a conclusion
For security reasons it might be good if orange/I fork the allowed programs to a FoL github page, where they won’t be changed until we’re sure any updates don’t have malware and stuff?
Not that I think that would… literally ever happen, because Zug is a Good Person and all that, but
2 Likes
If we’re committed to officially supporting tools then we could do that
depending on the tool that may not be ideal
like imo the site should not host the post-time-graph tool thing even if we allow it explicitly
1 Like
yeah nah i aint abt that
but like for multi-iso or whatever, sure why not
yeah I’m fine with that (with credit/attribution)
I’m not writing malware but it’s still a good security practice, especially since there’s a chance more people may start writing programs too
3 Likes
its also good for people who signed the agreement for the fol mods to see their stuff, but not the programmers for extensions (if that comes into play)
1 Like
idk if I get what you’re saying here
2 Likes
A forked repo links back to the original repo, and the git history is the same (up to the point of it being forked). New commits in the original repo will then need to be pulled to the new repo, but if done correctly, it should be unambiguous who the author/contributors are. At worst there will be merge commits from someone other than you.
(As an aside, do not squash commits in the PR for the fork because you may end up with conflicts in the next PR because the git histories will appear to be divergent.)
2 Likes
auyomating posts is pretty funny so it should be allowed™️
1 Like
oh by the way, if we’re standardising the practise of software like this there is like, an actual discourse api
i can see multiple benefits on giving access to specific functions it grants as it lets you shut it down at any time, know who has control of what, and I imagine its more functional than scraping the forum and such
Docs for it here:
https://docs.discourse.org/
2 Likes
Yeah there’s an api we can give keys for (and limit what you can Do with the key) i just admittedly haven’t looked into it much yet lol
Zug/story/whoever if you want to look into it and tell me what specific scopes you would need for a program i’d be willing to check it out
1 Like
There’s a Read-only scope that should suffice for pretty much any acceptable use in a 3rd party tool, and you can limit the key to the user it’s generated. I would recommend scrutinizing any request that requires more than that for a player tool. If someone wants to make a tool related for something like hosting that can make/edit posts, the most secure thing would be to have that person create a new account (that is never used as a player) for that purpose, and generate the key for that new account that has the larger scope.
1 Like