Notices by :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site), page 106
-
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 05:18:10 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
assembly sucks, just type in x86 bytecode directly -
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 05:03:11 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
@brainblasted @lanodan under `:instance`, afaik -
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 05:00:13 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
@ch405 no, but the object compaction & pruning did exacerbate the issue. -
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 04:57:05 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
@brainblasted @ch405 the real issue is the LEFT JOIN we have to do due to activity-object divide. this will be fixed in Pleroma 2, where the activity-object divide is slated to be eliminated. -
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 04:55:01 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
@brainblasted @lanodan yes, there's a performance penalty when ordering with a GIN index. this will be fixed once we get rid of the activities-objects divide. -
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 04:46:55 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
@rin
in conclusion, sorry for the long thread, and thank you for reading my ted talk ;) -
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 04:46:31 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
@rin
ultimately stuff like this is just growing pains and basically every community-driven project goes through them, so i'm not that worried about it.
as the project grows further, we will eventually have to tackle the HR and outreach issues, including the code of conduct third rail issue and decide how we want to document policies.
but it doesn't matter, because, even right now, if there were an incident where somebody got doxed, for example, we would most likely kick the person who did the doxing out anyway. -
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 04:41:14 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
@rin
i agree with your sentiment *there*.
codes of conduct and diversity statements are outreach tools. they may be useful from that side of the equation in some cases, but in our case, the fix is to fix the moderation hole so the main IRC channel has good moderation coverage driven by the people who are actually helping out there.
as I've said before, CoCs don't mean a damn thing without actual rules and moderation to enforce said rules.
people who ask for a code of conduct after an incident are really asking for a solution to the moderation hole that lead to said incident. they erroneously equate CoC with a moderation solution. a CoC itself is just the latest development in feel-good mission statements.
obviously #pleroma-dev has a different moderation stance: if you piss us off, you're gone, because it's our semi-private workspace and that's the end of it.
but #pleroma main IRC channel is a different beast entirely, and we need to improve the moderation situation there. the average user count is already at 200 people and growing. -
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 04:30:18 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
@rin
beyond that, moderation of people who are engaging the project space in bad faith because *they are looking for a fight* ensures the project space remains a productive and useful environment.
this has nothing to do with codes of conduct, and everything to do with ensuring that the people who cannot leave their bullshit at the door are sent elsewhere to express their bullshit.
if pretending to be a neo-nazi in order to fight people online is how somebody gets their jollies, fine, but they can do that in their own space, they don't need to be disrupting our space and, more importantly, wasting my goddamn time with this shit. -
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 04:24:08 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
@rin
i explicitly said that a code of conduct would not fix this problem. the solution is to give the people who are actually helping with support in the main channel appropriate access to deal with stupidity. this take does not reflect the consensus reached. -
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 03:39:00 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
we have options though.
one is to extract the list of URLs and check them against a domain DNSBL like URIBL.
another is to more carefully track each account's activities and use it to train the classifier. instead of allowing *any* previous accepted message, only allow messages that do not incentivize undermining as an initial message. this one is trickier though. -
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 03:31:36 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
the mitigation I included in Pleroma 1.0 was too naive and was undermined by people using the sharing features (likes and repeats) to spread the spambot's initial post. -
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 03:27:32 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
generally speaking, there isn't enough useful data in the message content itself to make a determination. the *metadata* however, tells a different story. -
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 03:26:45 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
anyway, the solution for the womenarestupid.site spam is to look at the behavioural side of the accounts. -
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 02:41:27 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
@yaaps it is indeed frustrating to watch people make the same errors over and over again without considering why we dont do what they propose in similar problem domains -
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 01:57:42 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
@DashEquals I mean yes if you never grant permission for a peer to write to your inbox then they cannot send you spam.
but no. there are other things we can do in the current security model. -
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 01:56:38 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
@ckeen that's the one -
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 01:54:05 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
the Nilsimsa stuff Gargron is doing is trivially defeated by simply adding more garbage to the message... and has a high false positive rate anyway. I guess I need to write about actual ways we can automate spam mitigations. -
:abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy: (kaniini@pleroma.site)'s status on Tuesday, 02-Jul-2019 01:38:27 EDT :abunhdhappyhop: :abunhdhappy: :abunhdhop: :abunhd: :abunhdhappyhop: :abunhdhappy:
@brainblasted they are quite spammy and since it's not a human but instead an aggregator, it's kinda annoying -
Dr. Roy Schestowitz (罗伊) (schestowitz@pleroma.site)'s status on Monday, 01-Jul-2019 23:20:34 EDT Dr. Roy Schestowitz (罗伊)
The "Linux" Foundation: we get $100,000,000 a year to promote #microsoft agenda
>Actual> #gnu #linux developer: I get a few dozens of dollars to buy myself bread. https://sparkylinux.org/june-2019-donation-report/ #sparkylinux