Oddbean new post about login | logout I also get that feeling. should I really be able to be naughty and someone's issue on a project I don't maintain? I have considered restricting it to just 1) user who raised the issue and 2) repo maintainers (OPTION 1). then I thought that complexity shouldn't be added to the protocol to solve potential problems that haven't manifested. this has to be traded-off against the adding to the protocol when other have started to implement it. This thread illustrates how this annoys developers and leads to partially implemented NIPs: nostr:nevent1qvzqqqqqqypzpms35h0lgrqe542lg8ly9dy0qrnp3jgjy43z4cmmds4mv7mkcnjfqyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qgwwaehxw309ahx7uewd3hkctcqyrnw36q5thdufr0d5mqjp2cren2azqgs2hsrqhrfqdqrzcpftgxkcgwdc6x So what is the problem with being able to change a status on an issue or proposal I didn't create on a repository I don't maintain? I think it is: 1) malicious actors who change statuses to create chaos (SPAM status events) - couldn't this be dealt with like other SPAM? 2) users who, operating in good faith, close or reopen an issue / proposal but don't understand the maintainers approach, or wider context around why this sort of issue / proposal should remain closed. perhaps there could be the option to add a 'locked' hashtag which means future status events from non-maintainers should be ignored (OPTION 2)?
yes, embrace the anarchy! nostr:nevent1qqst8q2jn0f6lumdzndxewuw8gxu058rcj8kyqgqklh7ju3vgxwky6gpp4mhxue69uhkummn9ekx7mqzyzsq3hh327t0h2dq6matqn5064cgj2zanl2stkj6s0lg4t2h5dty626e07k maybe this should be more sensible and only allow the maintainers / author to change the status.
I actually found it really useful because I have a bunch of different npubs for testing and whatnot and it was convenient to be able to review and close issues from the one while logged in as the other. But then I wasn't sure if it was a clever feature or a bug, so I thought I'd ask. 😂
I could reopen the issue, edit it again, and see who had closed it (so that I could ask them why), so it seems like the possible damage is limited.
I think there needs to be some sort of enhanced notifications when someone other than the author or maintainers close an issue so it doesn't go unnoticed. Also spam controls would need to be integrated. Wouldn't it be annoying if a bot closed all your open issue / proposals and opened random closed ones? Whilst there is some merit to this approach it does seem to be fraught with problems. why deviate from the normal approach that users expect and has less problems?
Well, a bot could also just spam the repo full with nonsense proposals. I guess you'd need a repo whitelist/blacklist option, really, in ngit. Then each project could determine how to define that list. I wouldn't put it in the maintainers file, though. Trying to account for malicious actors in each feature is too complicated.
Yes. I'm kind of new to spam prevention so the thought of working features around this excites me. Users could opt in/out of the reports bans by the maintainers. Although maybe a maintainer would prefer to manage these separately.
I'm closing this issue because I'm thinking this is actually an ngit discussion. Moved it to a new issue here: nostr:nevent1qqsf7hg7slt4uaapkqnhe0cpl84n5a2v93anqedrzkvwv30n3hc9xjspp4mhxue69uhkummn9ekx7mqzyr7jprhgeregx7q2j4fgjmjgy0xfm34l63pqvwyf2acsd9q0mynuz36ecrx
test
Sorry. :-) Just checking to see if replies refresh. Had to refresh the entire page, after the last note, but I think it was just slow.
I think the whole site needs to be thoroughly debugged for reactivity issues like this. I'm in the middle of a refactor so it will be best to do this after that.
I actually found it really useful because I have a bunch of different npubs for testing and whatnot and it was convenient to be able to review and close issues from the one while logged in as the other. But then I wasn't sure if it was a clever feature or a bug, so I thought I'd ask. 😂
I could reopen the issue, edit it again, and see who had closed it (so that I could ask them why), so it seems like the possible damage is limited.
I think there needs to be some sort of enhanced notifications when someone other than the author or maintainers close an issue so it doesn't go unnoticed. Also spam controls would need to be integrated. Wouldn't it be annoying if a bot closed all your open issue / proposals and opened random closed ones? Whilst there is some merit to this approach it does seem to be fraught with problems. why deviate from the normal approach that users expect and has less problems?
Well, a bot could also just spam the repo full with nonsense proposals. I guess you'd need a repo whitelist/blacklist option, really, in ngit. Then each project could determine how to define that list. I wouldn't put it in the maintainers file, though. Trying to account for malicious actors in each feature is too complicated.
Yes. I'm kind of new to spam prevention so the thought of working features around this excites me. Users could opt in/out of the reports bans by the maintainers. Although maybe a maintainer would prefer to manage these separately.
I'm closing this issue because I'm thinking this is actually an ngit discussion. Moved it to a new issue here: nostr:nevent1qqsf7hg7slt4uaapkqnhe0cpl84n5a2v93anqedrzkvwv30n3hc9xjspp4mhxue69uhkummn9ekx7mqzyr7jprhgeregx7q2j4fgjmjgy0xfm34l63pqvwyf2acsd9q0mynuz36ecrx
test
Sorry. :-) Just checking to see if replies refresh. Had to refresh the entire page, after the last note, but I think it was just slow.
I think the whole site needs to be thoroughly debugged for reactivity issues like this. I'm in the middle of a refactor so it will be best to do this after that.