[Feature Request] PronounDB integration/public facing api for querying pronouns based on social media handles/ids

[solonovamax]

There's another project, pronoundb, which allows you to query an API to return someone's pronouns using a social media handle/id that they have authorized.
So if I were to sign up to pronoundb with my discord which had the theoretical id of 123456, then I'd be able to send a request to https://pronoundb.org/api/v1/lookup?platform=discord&id=123456 and it would return a json object specifying my pronouns.

Right now, we currently have 2 different services that basically accomplish the same task. (Of allowing people to share their pronouns)
So, I'm opening this issue because I think it'd be worthwhile to merge the functionality of the two services.
You could make the service entirely opt-in for the user, so nobody would be at risk of accidentally exposing themselves.

And if you don't feel like making all the required features for supporting a bunch of different site integrations, then you could just make a public-facing API that allows people to query the pronouns of an arbitrary pronouny user, which could then be integrated into pronoundb, thereby separating the two services but allowing them to interact with each other.

TL;DR cool people know how to write cool code, and I think they should integrate their code so it can work together and make cooler code.

Also, I'm @'ing @cyyynthia because she's the owner of the pronoundb repo and I'm too lazy to make two issues for this lol

[falkirks]

I'm happy to do whatever to make this easier for @cyyynthia if she wants to integrate somehow. But it does seem like pronouny and pronoundb have quite different approaches to neopronouns and custom sets which might make this impossible. My end goal with pronouny was an API and that never really panned out so would love to support https://pronoundb.org/ however I can if you need anything.

[falkirks]

Also pronouny already has an API to pull pronouns out of a given username (eg: https://pronouny.xyz/api/users/profile/username/noa). You could use this to import pronouny data if you liked. If you wanted to use this with whitelisting I would suggest using the listed field on the pronouns but you could do other ways as well.

[solonovamax]

Ah, I didn't know you have an API. I'd def put some docs somewhere on the site since I didn't see any there. Like if you had some button called "API" with some simple docs, that'd suffice. (or even if it just redirected you to a github wiki with all the details)

But as for neopronouns, based on what I've seen on one of the pronoundb issues, (cyyynthia/pronoundb.org#3), they're open to allowing uses to use neopronouns, but just don't have a good enough UI for them, nor do they have a good method of adding all the neopronouns someone might want.
Integration with pronouny solves both of these issues.
Because if you delegate the pronoun selection to pronouny, then pronoundb would no longer have to deal with selecting pronouns, and instead would just have to deal with distributing them.
Of course, it'd require completely rewriting the way the API returns pronouns, and instead returning a JSON array of pronoun names, but that shouldn't be too hard to implement, and given that only 379 people are currently using it, now would be the perfect time as there aren't many apps using it yet.
I might look at setting up some kind of a basic thing for pronoundb that allows you to connect a pronouny, but web dev is not my strong suit; I'm a java guy.

Also, one thing I'd like to point out is that it seems the API returns following, but not followers. This isn't a feature that's needed by any means, but is this intentional? (Also, I'm assuming anyone in the "friends" category is someone who's both following + followers)
Also, what's the "these pronouns are private, not for noa" listed for u/noa? They link to u/yaromil todd when you go on pronouny (not shown anywhere in the API) and have the content of "yikkkedetsen"

It also seems you've listed ids for individual pronouns and users. Is there a way to query that from the API, or no?
Really, you just need some docs somewhere lol

[falkirks]

@solonovamax The API docs aren't public because the API is for internal use. I made it when I was just starting to learn web development and it's not the most sensible thing. I wanted to make a public facing one seperately, but have not had time for this.

As for the specific API questions

• It returns following because this is contained in the user object definition, so it can be pulled in the same request. And for most cases the frontend needs both. Ideally this would be an optional addition to this route, but its an internal API so that hasn't happened.
• Friends are calculated by the frontend by intersecting this list and the list of followers of the user. So that's a frontend only thing/
• That's just a silly thing where I was testing behaviour. Those are "custom" pronouns created by another user, so they won't be listed under that user unless they are currently in use by them. They belong to "u/yaromil todd" but aren't being used by "u/yaromil todd". Normally it would be impossible to use pronouns that belong to someone else but I was testing a thing

[falkirks]

And as for API routes you can look at https://github.com/pronouns/main/blob/master/modules/users/server/routes/users.server.routes.js for user related ones and https://github.com/pronouns/main/blob/master/modules/pronouns/server/routes/pronouns.server.routes.js for pronoun related ones. Some are restricted to logged in users only but that should be fairly obvious I hope.

[cyyynthia]

But it does seem like pronouny and pronoundb have quite different approaches to neopronouns and custom sets which might make this impossible.

I've decided to not support them due to the additional maintenance troubles this would bring and the moderation issues in case of custom sets. The format PronounDB uses to store pronoun sets is also rather incompatible with such (although it could always be worked around and/or changed).

It's also worth noting that despite not having a large userbase, the pronoundb.org domain has been handling 2M+ requests for the past month and has been distributing in total 1.9GB of data. Not working with identifier-based pronouns and shove them entirely in the payload would (in a pessimistic scenario) multiply by 2 the outbound traffic, which is something I'd be more than happy to avoid. It also completely kills any hopes of decent internationalization which is something I may want to look into in the future.

Integration with pronouny solves both of these issues.
Because if you delegate the pronoun selection to pronouny, then pronoundb would no longer have to deal with selecting pronouns, and instead would just have to deal with distributing them.

This sounds more like merging projects than integrating, but w/e. The problem for me here is that PronounDB is no longer the data broker for pronouns which makes me dependent on a third-party service for the provision of data, the format of the data I receive, and any form of legal text the third-party is using (Privacy Policy or Terms of Use for example).

I might look at setting up some kind of a basic thing for pronoundb that allows you to connect a pronouny

As falkirks mentioned, the differences between the approaches we've taken on pronouns handling makes integrating a hassle, and you'd at best only get a partial integration.

But, if you really wish to try, either Pronouny or PronounDB in a safe & robust manner, one of the services would have to implement an OAuth layer, so the other can go through an authorization flow before the data is passed. You can't just expect users to throw in a text field their ID and expect things to work.

Also note that, because of French laws which pronoundb.org abides by, I will not be sharing all of someone's linked accounts & their pronouns to a third party without their explicit approval (so through an OAuth screen). This is to ensure no sensitive information is leaked out to the public, and because it'd be disrespectful for user's privacy.

TL;DR cool people know how to write cool code, and I think they should integrate their code so it can work together and make cooler code.

Sure, but people also make different and incompatible choices, and some prefer to be lone wolves 🐺

[falkirks]

It also completely kills any hopes of decent internationalization which is something I may want to look into in the future.

This is such a huge issue and something that I didn't think about when building Pronouny. I'm glad that's something PronounDB might support nicely in future.

This sounds more like merging projects than integrating, but w/e. The problem for me here is that PronounDB is no longer the data broker for pronouns which makes me dependent on a third-party service for the provision of data, the format of the data I receive, and any form of legal text the third-party is using (Privacy Policy or Terms of Use for example).

Yeah I'm also unsure what the purpose of this would be. I don't think any of the pronouny code or sytems should really be relied on in a continuing way. Things are quite fragile and brittle. But you are welcome to any of my code if it helps (but I really doubt it will) and I am happy to relicense my contributions if there are legal issues with your license.

the pronoundb.org domain has been handling 2M+ requests for the past month and has been distributing in total 1.9GB of data.

I am at ~25M and 279.5 GB this month so I think your way of handling data is far more sustainable lol

Sure, but people also make different and incompatible choices, and some prefer to be lone wolves 🐺

I also want to add that I value the choices you made and the reasoning you put into them. I made this app for a specific and different context. And if you do ever want support with PronounDB I am really excited about software like this and happy to take issues or provide some server space (although it sounds like your requirements around that are fairly specific).

[cyyynthia]

I am at ~25M and 279.5 GB this month so I think your way of handling data is far more sustainable lol

You also have more data to carry than me from what I've seen, and if I really wanted to optimize the payload sizes I could use shorter keys; it's not something I'm too worried about, but keeping it down is still preferable.

And if you do ever want support with PronounDB I am really excited about software like this and happy to take issues or provide some server space (although it sounds like your requirements around that are fairly specific).

I'm fine with the hardware I currently have and I can afford an upgrade if necessary, I could even afford spinning up a k8s cluster and let the cloud:tm: magic scale up infinitely for me. Scaling up a project like PronounDB is super easy since it's literally spawning a new instance and balancing the load between the two (or getting a new server and let Cloudflare do the job), compared to some of my other projects with involve real time communication and where I need to be able to pass messages around the entire cluster in a few ms, not the same level! Thanks for the proposal though, appreciate it 😄

As for maintenance help, for now there are not many modules and the server-side abstraction lets me add new platforms in a matter of minutes on that end. The only tricky part is smoothly integrating into the apps, which is easy but time consuming. For now since I haven't reached version 1 things are rather volatile (the structure might change, the extension popout will definitely get a complete rework, ...) but in the future contributing will be much easier if you really want to help out!

[solonovamax]

ye, this issue was never made as a "this is something that needs to be done now"

I made it more as a "hey, those two things to some cool stuff that's kinda similar. Is there maybe a way to integrate them?? Because that'd be pretty cool."

@solonovamax The API docs aren't public because the API is for internal use. I made it when I was just starting to learn web development and it's not the most sensible thing. I wanted to make a public facing one seperately, but have not had time for this.

Fair. Time is pretty hard to come by nowadays.

I might look at setting up some kind of a basic thing for pronoundb that allows you to connect a pronouny

As falkirks mentioned, the differences between the approaches we've taken on pronouns handling makes integrating a hassle, and you'd at best only get a partial integration.

But, if you really wish to try, either Pronouny or PronounDB in a safe & robust manner, one of the services would have to implement an OAuth layer, so the other can go through an authorization flow before the data is passed. You can't just expect users to throw in a text field their ID and expect things to work.

Yeah, when I said "set up some basic thing for pronoundb that allows you to connect a pronouny" I meant more "I'll set up a simple text field and some really simple (and probably very bad) code that sends out HTTP requests as a POC to see how something like this might work in a real implementation"
I'm not a web developer in the slightest and probably couldn't do something that works well for this. I just might fuck around and see if I can make something interesting at some point.

I wasn't thinking that I could make something that would actually be used, just something I could host locally and mess around with.
Like I theoretically probably could implement an oauth layer in one of the apps. But that also sounds like a lot of effort for just fucking around lol. And I'd probably get bored halfway through and drop it & move on to the next project if I started doing that.

Also note that, because of French laws which pronoundb.org abides by, I will not be sharing all of someone's linked accounts & their pronouns to a third party without their explicit approval (so through an OAuth screen). This is to ensure no sensitive information is leaked out to the public, and because it'd be disrespectful for user's privacy.

That's fair. As someone who cares a lot about privacy, I completely understand wanting to keep your users' privacy.

But one option for a kind of pronouny integration would be to have the API just return their pronouny username, which an application could then use to query the pronouns there. Of course, you'd have a nice big sign saying "this will share your pronouny username publicly, are you okay with that" to any user attempting to enable it.
It'd be jank, and it might not work the best, but it is a way to avoid increasing the json payloads by a lot, while also allowing for people to (sort of) link neopronouns to their account.

(This isn't really a long term solution. This is just me throwing out ideas and seeing what others have to say about them. I understand that designing web apis isn't a quick and easy thing, and it's something you need to put thought into.)

Sure, but people also make different and incompatible choices, and some prefer to be lone wolves wolf

Of course. I completely understand that. I just wasn't sure whether both projects were aware of each other, and thought something cool might come of it. As I said at the start, this isn't anything that I see happening in the near future. This is just me saying "this would be pretty cool if it could theoretically happen" and just shitting out ideas and whatnot.