Yep, exactly - I don't think you'd want to for security/privacy reasons let alone just raw data reasons. It would be a pain to manage.
Yeah, we agree on that. No centralized data store ;-)
Besides the discovery portion (which could be useful for adding additional authentication providers like how Forem has Twitter & GitHub), it doesn't seem to bring much more to the table.
Yeah, still have to go through the entire spec to see if it's enough or not and/or if it's flexible enough to be extendable. The jury is still out on IndieAuth. I also wonder what we can borrow from ActivityPub and if would make sense for us to become a server for it.
Yeah, that's my "ideal" view if this functionality was here tomorrow. Just from that written example though, my brain says "looks more GraphQL-esque than REST" - that isn't a problem per-se but I didn't see it that way when I wrote my previous comment - brains are weird. 🤷♂️
Interesting. I also think of API Gateways that are able to stitch different microservices together to build a response and they predate GraphQL in a way. The difference here is that each "microservice" will be a Forem installation with the same exact code. The technology behind all of this is an avenue to be explored. I suspect how we build "discovery" is going tell us what the right architecture here is.
Here is a crazy thought - why do we need an authorative version of a profile? I don't think a single authorative version is needed but I do think somewhere that you can view these linked accounts across Forem instances would be fundamental.
Agreed. Linking one another is an opt-in. Fundamentally a person could spend their online life using two Forems that never talk to each other and be fine with it.
Given every Forem instances has the same core-code, every instance could technically have this page and do a "network" query across your linked accounts across different Forem instances.
Back to the discovery part ;-)
Without knowing what the code behind a specific instance of Forem is doing (knowing that people could, in theory, modify it to do custom stuff), the only way for the privacy to exist is to never link between them.
True that! As Forem can be modified and self-installed, the trust level by default should be share nothing, but then if you share nothing, as you say, what's to be gained to link them? Forem's code is AGPL which requires modifications to be published in theory. This might help. Another possibility is to trust only servers managed by Forem.com but that could limit the network effect.
Look, I'm happy to talk about this stuff all day and bounce ideas etc off of. Feel free to reach out at any point. 🙂
Thank you!
For further actions, you may consider blocking this person and/or reporting abuse
Yeah, we agree on that. No centralized data store ;-)
Yeah, still have to go through the entire spec to see if it's enough or not and/or if it's flexible enough to be extendable. The jury is still out on IndieAuth. I also wonder what we can borrow from ActivityPub and if would make sense for us to become a server for it.
Interesting. I also think of API Gateways that are able to stitch different microservices together to build a response and they predate GraphQL in a way. The difference here is that each "microservice" will be a Forem installation with the same exact code. The technology behind all of this is an avenue to be explored. I suspect how we build "discovery" is going tell us what the right architecture here is.
Agreed. Linking one another is an opt-in. Fundamentally a person could spend their online life using two Forems that never talk to each other and be fine with it.
Back to the discovery part ;-)
True that! As Forem can be modified and self-installed, the trust level by default should be share nothing, but then if you share nothing, as you say, what's to be gained to link them? Forem's code is AGPL which requires modifications to be published in theory. This might help. Another possibility is to trust only servers managed by Forem.com but that could limit the network effect.
Thank you!