Having problems registering on Coin Return? Please email support@coin-return.org, and include your PA username and PIN.
For those who don't know, forums.penny-arcade.com will be closing soon. However, we're doing the same kind of stuff over at coin-return.org with (almost) all the same faces! Please do feel welcome to join us.
For those who don't know, forums.penny-arcade.com will be closing soon. However, we're doing the same kind of stuff over at coin-return.org with (almost) all the same faces! Please do feel welcome to join us.
For those who don't know, forums.penny-arcade.com will be closing soon. However, we're doing the same kind of stuff over at coin-return.org with (almost) all the same faces! Please do feel welcome to join us.
For those who don't know, forums.penny-arcade.com will be closing soon. However, we're doing the same kind of stuff over at coin-return.org with (almost) all the same faces! Please do feel welcome to join us.
UPDATE ON TIMELINE: The Future of the Penny Arcade Forums
This discussion has been closed.
Posts
Like, $10 USD could round to $14-15 for others and also effectively cull some international participation; it definitely restricts me from wanting to use certain streaming services, for example
3DS Friend Code: 0216-0898-6512
Switch Friend Code: SW-7437-1538-7786
1) one thing I always felt limited new people showing up was how for the past two years (at least) most of the forum was hidden and unreadable unless you signed in. I still think of games & technology as the main thread, so not being able to see it when people might be looking for opinions or help on a game always seemed to blunt interactions with the site.
2) in the new forum I'm Zoro, you can't be Zoro.
We don’t have the advantage of a larger forum population like Gaia or SA, and thus don’t have that 00s internet cultural fame (or infamy) that something like SA can lean into. And keep in mind even those communities are struggling to maintain a stable population of users. Forums just aren’t where people go these days to hang out on the internet.
I understand this community is important to people, but at some point you have to make peace with the fact that this forum will shutter one day. All good things, etc. but we can buy at least a few more years for everyone.
I've been deep in the throes of a midlife crisis and this definitely feels like that in spades. "Remember all the anchor points to your early life that made sense? Systematically lose all of it and reinvent yourself in your 40s. Get wrecked."
Thanks to everyone, mods especially, who put a lot of their time, care, and life into this place. Sincerely. We're getting old. I look forward to us keeping things together as best we can. Time marches, eh?
3DS Friend Code: 0216-0898-6512
Switch Friend Code: SW-7437-1538-7786
I'm not saying we should be out there actively recruiting users, but I would say that making ourselves inviting for new users would do nothing but help this community stave off the inevitable heat death of any online community.
Plus there's the financial aspect. This will be community funded, and you need a critical mass to keep that going. Otherwise, you're going to get gradual attrition followed by a cliff.
But if we attract new users, that's extra candidates for modship from a pool of people who don't yet realize the abject horror of moderating.
Legos are cool, MOCs are cool, check me out on Rebrickable!
or, and hear me out, we could just make everybody a mod
Mods: "Ok everyone, we're elevating everyone to mod status. Existing mods will be upgraded to senior mods."
Switch ID: MNC Dover SW-1154-3107-1051
Steam ID
Having done a little more digging into this myself, I think my hope in this feature was misplaced. Vanilla has support for jsconnect, and some other more standard technologies like Oauth2 and Saml, but always as a client not as an idP. There are plenty of articles on integrating Vanilla as a slave to an outside authenticator to smooth onboarding of users from a 3rd party system into a vanilla forums instance, including both account creation and SSO. But so far I haven't found documented solutions for going in the other direction.
There may still be a way to make this concept work but it might require a custom Oauth2 add-on with the additional functionality we require, and convincing Vanilla to activate it in our Vanilla Cloud instance.
I'm on the fence about such an idea. Something like "Pay $1 a year" will be doable for most, and for those of us with a little extra we should be able to put more money in specifically for the purposes of long time posters having their dues paid anonymously so there doesn't have to be any feeling of patronage for the people who can't manage it.
At the same time, it'll automatically turn some people off, even if they don't have to pay it, and so those people will just be gone or permanent lurkers, and I definitely don't want that.
Probably the best method is once a year funding drives like they do on Wikipedia (or if you're old, PBS). Those who can pay will, those who can't don't have to feel obligated or guilty.
But fuck you — no, fuck y'all, that's as blunt as it gets"
- Kendrick Lamar, "The Blacker the Berry"
People will come to see us draw the most beautiful horses.
If the future is volunteer moderation and community donations, then I'd argue we need to do all we can to support that. And imo, that means moving to a platform that has a balance of cost vs technical supportability. That might mean folks have to use external image hosting for example. I'd also argue that a re-org is required. We have multiple threads of the same topic in different places. If we can condense the forum by 30-50%, that reduces the moderation requirements as well.
I imagine that the software we want to go to will try to have tools to migrate to them.
*E: often the case with when you try to leave a service: they're going to act like it is impossible to migrate, only for the provider you move *to* to fix it all for you with one button.
--
I'm going to wait with long posts about this subject until we have separate threads, but I definitely want to talk more about the financial structure of this.
This conversation may also change based on what technology ends up being used. I could see a world of let's plays, game tips/tutorials, reviews, etc that could drive traffic if those specific items could be crawled by search engines. Especially given the state of gaming sites today, I could see community reviews drawing some folks in, especially for smaller/indie games. I loved reading folks reviews for Pathologic 2 for example.
edit: I'd also assume any future state would involve ads as well as I'm sure it's only a small % of folks that donate for software (discord or reddit for example).
This said as someone who has been involved in the past with one of those.
Put a password gate in the front page and have forum members never shut up about how they're a member of the new super secret forums and you can't join.
Don't worry they'll tell you.
@Ramius This was my conclusion too. I read up on the docs yesterday and it struck me that all of the docs on jsconnect described Vanilla as the auth client, not as the auth provider. I wanted to sleep on it and check again before bringiing it up.
I don't know what the team's appetite is for custom coding, but it might be possible to use JWT instead.
the "no true scotch man" fallacy.
If Vanilla is following basic best practices, then our passwords here should be stored as hashes and effectively not exportable. There are ways to migrate hashed passwords, but there will be both technical and procedural controls preventing arbitrary access to those hashes. Whether Vanilla can allow for that export is a big x-factor, and whether those hashes are usable on the destination forum is another big x-factor.
I'm not saying it's absolutely impossible, just don't count on it.
The alternatives that Ramius is looking at involve using our current forum as an authentication system. You log in here, Vanilla vouches for you, and the new forum trusts that login and gives you access to your account.
The challenge right now is that Vanilla's docs entirely talk about that working n reverse. Vanilla trusts some other site or system to authenticate you.
Again, none of this is impossible, it's just another challenge to overcome.
the "no true scotch man" fallacy.
And I think it is overcomplicating things... we could just export the usernames, which we can do without database access, and put them in the new software as "protected - verify"
If someone registers with one of those names, we automatically send them an email with a confirmation code, and a link to the current PA forums set to a new private message to a receiving inbox where you, as that user, paste the confirmation code in and hit send.
Like, the email could be:
Vanilla emails the address associated with that user with the contents of the DM, which is monitored by a service that validates the correct code from the correct name and flags the user in the new system as verified.
This is a one-day, completely viable solution that avoids us needing to get in the weeds with migrating people over, especially if they don't all want to come along for the ride.
I admit that most of my experience is second-hand, usually on the side of trying in SPs to our IdPs here at the university. I've heard horror stories of what it took to get Shibboleth running, and the "fastest" link I ever set up was getting GitLab to use Facebook/Google for OAuth / SAML. But I don't believe that Google/Facebook support attribute binding the way you are talking about (to link current identities to future identities).
Your best bet, as always, is going to be email. Off the top of my head, I could see it going like:
- You get a list of emails of registered users from Vanilla.
- You copy these into an independent database somewhere.
- You feed that database in to whatever future solution we use to seed user accounts.
- You then tie into an OAuth provider (or many).
- When a user first logs in, the forum does not let them immediately set a username. Instead, it validates that their email is correct. If it is, then it prompts them "Is this you?" If so, it links - if not, it gets flagged to a moderator to sort out (our population is small enough to viably handle manual intervention)
- If the user validates their email and there's no associated account, then the user is prompted to choose a username. And if they choose one that is already taken, they get told no AND a flag is raised to the moderator to follow up. (this may be turned off after the initial migration).
With the above proposal, you'd lose existing passwords. However, having gone through 2 implementations where we have tried to keep existing passwords (because heaven forbid professors ever change their passwords), it is doable with enough planning and communication.
And then from there, because you are using one of many OAuth providers, you could wire in more advanced security like 2 factor authentication, passwordless auth, yubikeys, etc. through them without needing admin overhead locally.
Is there any means to do an API-based login and get a token back from vanilla on success for the user?
If so, we could set up a middleman login service - something super lightweight like a lambda - that first attempts to log in to the new IdP (cognito, auth0, etc), and if no user is present, make an attempt against vanilla. If the user exists there, we happen to have the username and password on hand to create the new user, which means from that point forward that login will be managed by the IdP and vanilla won't get called for it any more.
It does require people still have access to the email attached to their forum account, which I know isn't 100%.
Given the bugs and issues people have experienced with updating profiles, getting that sorted might be an early stepping stone as a precursor to core work.
no, they do not need their forum email address. They just need the ability to log into the forum. If they cannot log into the forum, any kind of automated flow is going to be a pain in the butt / impossible and we would need to defer to manual interventions.
All they need is their username, and the ability to log in at PA. What email address you choose to register with at the new forum is immaterial.
This is basically my expectation for how the migration would work too.
I'm personally taking a twofold mindset right now: I want to support the mod council and Ramius in the strategy they think is best even if it's not the strategy I would pick, while simultaneously doing what you have done here in suggesting different strategies.
the "no true scotch man" fallacy.
EDIT for post just below: ah, hadn't considered that. a little extra effort for those who do want to opt-in would be an acceptable ask and nice for those who don't.
Doing a method where migrating your user is wholly opt-in, and we don't have any personal info (including email address) on the other side would likely calm those concerns.
Using a separate SSO provider to log in to the new site also prevents this particular flavor of headache if the forums need to change platform again in the future. If we, say, decide that XenForo isn't working for us and then go to Flarum (not saying this is likely, just an example) then we can tie in the same SSO provider.
It's also generally possible to do the kind of user migration that syndalis described above, while using an external SSO provider for login. The SSO provider would just match against the imported user accounts.
I'd also argue it's better from an infosec standpoint to let a service that lives and breathes auth to do the auth, rather than rely on an auth component baked into the forum software.
the "no true scotch man" fallacy.
As someone who is currently trying to figure out how to get Shibboleth working with dockerized Node/vue instances, I assure you, whatever stories you've heard have undersold the pain. I have one of the primary developers (Scott Cantor) number saved in my phone at this point. He's not a fan of me.