I’ve used unions in C, ages ago, and I think I should probably feel dirty for doing so. I’m not sure they’re the same type of union you’re talking about though. At least, I hope not.
They’re the same as far as I can tell.
in TypeScript you can have a type type A: B | C meaning A can be either of those, a union. It works like magic for when you need to have structured data of different kind at the same level. It works somewhat similarly to how you’d use tagged enums in rust (which are enums that can hold unique data for every enum option).
Dart is a bit of a mess in that regard and it’s made worse by the fact that dart is bound by the “must complie to JS” requirement. Still, it’s a reasonably nice langauage and flutter makes cross-platform code manageable (even though on iOS it looks just like Java apps looked on windows in early 00s).
Yea, that’s what C/C++ unions are as well… It doesn’t seem like good programming practice in all honesty, as overloading generally does the exact same thing.
As for cross platform, like I said, I have no prior experience with Dart/Flutter, but I actually really enjoyed my time with C# and Xamarin. Didn’t do much on iOS… because Apple… but Android and Windows apps always looked native (at least a recent era of native) out of the box.
Well no, in C the unions are untagged, meaning you don’t know which exact version of it is relevant. In rust and TypeScript you still have the type information so you know which inner type is available and you can do nice things like exhaustive switches (the compiler reduces the a syllable types as you verify they don’t apply).
TL;DR: TS’s type system is really really good with lots of fancy metaprogramming: it’s even Turing complete for the extra pain if you can’t let the memory of C++ templates go!
It’s available, but any chats that are identified as ‘used to spread pornographic content’ are completely blocked on the iOS app - even the icon for the chat gets hidden. This cannot be overridden via the desktop client.
Rejoice, I removed all the incriminating FIXMEs and published the source code at https://github.com/farcaller/ravenry.
Now, any volunteers? It’s still a hot mess and it needs so much more work to make it usable.
I’d love to help test it out (and contribute, if I can get my head around flutter 
)
bird nerds out
Excuse me shouldn’t it be rookery? 
I’ll work on getting it loaded as soon as time allows. I have an interesting and somewhat unique platform to test it on.
1 Like
Me going through the play store questionnaire: eeeeeeeh.
Apparently I need to go through the full app review process to be able to deploy the internal only builds from CI for android. How does that make any sense.
iOS, in the meantime, is fully automated now.
What does that entail?
That’s when the trained humans go and check out your app. I parked the test account in the aura’s cafe and hopefully they (the testers) will be excited about the chat functionality.
Okay, that’s about what I thought. @Accipiter, everything okay with this?
(As Tasho just thought of there are concerns about the rule against ‘shared accounts’ here, as well as the potential IP problems of exposing this further. It’s the wolf’s call though.)
You’re technically not supposed to have accounts shared between users
I think my creating an account for a playstore reviewers is more reasonable then telling them to go to wolfery.com to register after all the work I did to never explicitly mention wolfery 
@Accipiter we need service accounts here! already you might have seen some recent traffic coming from github servers (it’s technically within the rules because that one isn’t shared but alas).
To be clear, I think this is a good exception case for that rule, however I want Acci to chime in first. This is a “first time we’ve run into it” issue.
Chiming in!
Usually, we don’t allow shared accounts. It is just a recipe for trouble.
But to create an account for playstore reviewers to use, is a reasonable exception. So, I’ll allow it!
If it would be of any help, I can also setup Mucklet.com to have that API that will fetch you an array of available mucklet servers (basically Wolfery and Wolfery Test Server), so you don’t have to directly point them to Wolfery.com.
Username/password security concerns
But when it comes to security, my main concern with this app is rather the username/password login. While I think @farcaller can be trusted, it is still from a Mucklet point of view a third-party client, which requires the users of the client to trust that their username/password are not in anyway stored, logged, or harvested by the client.
This can of course be solved with oauth2, and eventually I will need to disable username/password login for such security concerns.
But before I do that, I want to have bot tokens in place, so that bot scripts may still connect without the need of oauth2 authentication.
Oh well.
But go ahead with this account!
1 Like
Yeah, we discussed it previously and I’d prefer an API where any option of ended up in Wolfery without user typing something isn’t an option
Wait no, that’s not how it’s supposed to work! What about—ahem—peer code review and signed builds.
private link?
Let’s actually look more into this. I’ll need a custom client id / redirect for auth.mucklet.com. I think I can just open the link in the browser that will be a safe place to log into google and then mucklet can redirect me back into the app.
Just a staff forum link 