Open highfalutin opened 3 years ago
j-ro
commented
3 years ago Hi there, this project is somewhat defunct, and there is no demo server to test against. That said, there's already a lot of Civi work that's been done that you probably should start with: https://civicrm.org/extensions/civicrm-osdi-contact-sync
highfalutin
commented
3 years ago Thanks! Yes, I'm taking advantage of that previous work where I can. Are you saying that the OSDI standard is defunct, as in you don't expect it to be adopted by anyone else?
j-ro
commented
3 years ago I'm not sure anyone can really answer that. We (Action Network) already implement it and continue to expand on our implementation. Others do too. Perhaps others will pick up the standard.
highfalutin
commented
3 years ago I'd love to hear more about what you mean by the project being defunct. I got the invitation to Action Network's Integration Partnerships Program and just signed up, so perhaps we'll be in touch there.
j-ro
commented
3 years ago I mean, check out this repo, there's been no updates in years, I don't think the committees still meet, etc...
joshco
commented
3 years ago Try the sandbox used in this tutorial: http://opensupporter.org/osdi-101-zero-to-person-signup-helper/ You don't need to be part of Action Network's partner program use it or to implement the spec. What's described on Action Network's site as the Action Network API is just the reformatted OSDI spec.
highfalutin
commented
3 years ago Thanks @joshco. I need to specifically integrate with Action Network, so I need to pay attention to the particular way they've implemented the spec. But I'd like to make my tool usable with any service that implements OSDI -- assuming there are (or will be) others out there.
Re the sandbox you mentioned, that's great to know about. I signed up for one. Unfortunately it doesn't seem to be fully functional -- I can't seem to use OData filters or modify email addresses on existing records.
joshco
commented
3 years ago I haven't looked at it in a while, can't remember which parts it supports. "fully" functional will always depend on the integration profiles supported, and some will have different features. For a while, Action Network wouldn't let you change an email address on a supporter since that was the unique key. Things change... If you are a rails dev, I can give you access to the repo.
The point of the project was to create a level playing field, so platforms and apps would compete based on the merits of their products, not the scale of their ecosystems, and we would have an ecosystem unified on a single protocol.
It took alot of work, by a committee that met weekly from early 2013. Action Network joined in November 2013, when the spec looked like this: https://github.com/wufm/osdi-docs/blob/precan/README.md
That labor continued, with the product being co-mingled IP, through January 2019, 60 days before the ActionBuilder launch by the AFL and Action Network. Action Network had different goal, which it what you see on their site; 1 of 2 APIs with scale in the progressive ecosystem.
joemcl
commented
3 years ago Hi @highfalutin ! It's great that you're building on the previous work of @4ndygu to connect CiviCRM with remote OSDI supporting services. I am and was very involved in the CiviCRM community - I and @j-ro advised @4ndygu when he was working on his extension as a Googe Summer of Code student with the CiviCRM community.
I think the most active and interesting work happening lately to advance a standard (that also builds on and supports the OSDI concept) is Parsons, see https://move-coop.github.io/parsons/html/index.html and in particular this - https://move-coop.github.io/parsons/html/action_network.html .
It would be super cool to create a Parsons connector for CiviCRM!
highfalutin
commented
3 years ago Thanks for the comment, Joe. Parsons seems great at first glance, and it does seem to be in the spirit of OSDI / share some of the same motivations. In terms of the actual product, it's very different (a python package in Parsons' case, an implementation-agnostic RESTful API standard in OSDI's case). Happy to chat about the possibilities for connecting Civi with various things over on the Civi Mattermost. Thanks for being an advisor on the previous OSDI-Civi project!
joshco
commented
3 years ago @joemcl , please don't conflate democratically decided standards that create a level playing field for new entrants on the client and platform side with open source connector libraries for proprietary APIs(*) that help entrench larger players who compete based on the scale of their ecosystems. ( At least don't do it here. )
The fact that one needs to express this request illustrates the issue:
It would be super cool to create a Parsons connector for CiviCRM!
*= The Action Network API is really just a pink-washed, plagiarized OSDI spec, built by pooled intellectual property and labor by the community. The core architecture was spec'd, prototyped and published by senior engineering resources within the community before Action Network even joined.
The commit before Action Network joined https://github.com/wufm/osdi-docs/tree/precan
The scale of that ecosystem starting from 0 in 2014 to a critical mass of adoption in 2017 is due to that community labor as well. I did the math at one point, summing up from tech committee attendance records from 2013 - 2018. Rough numbers ~ 1600 hours of labor from just the tech committee alone. (2000 hrs/yr is loosely 1 FTE) AN attended 4yrs (2014-2017) which is 130 meeting-hours.
So there's 1470 hours of labor other people put in because the stated mission was to help everyone, and move from CompuServe/Prodigy/AOL style proprietary walled-gardens to an open internet web model.
Instead, all of that labor was repurposed to provide dominant control for Action Network and the AFL-CIO over what AN described in 2014 after the VAN innovation event: "one of two widely adopted progressive APIs" alongside VANs.
That's unfair, wrong, and super hypocritical for a union.
Joe, your contributions were significant, and Civi (or other Joe preferred tools) should get the same benefit from the scale of the OSDI ecosystem we all built.
if Civi determines that it's more practical to write the code once (an OSDI service with the right integration profiles) in the Civi side rather than N times for different client libraries (and maintain them) then it should.
Governance-wise, Democracy is what I wouldn't get go of and they wouldn't accept, and after the Bernie Breach, unification was happening fast enough that it was about to be too late to stop it.
At the end, had PDI had been ready 30 days earlier to join (before I recused myself) we'd be in a different world. My records show they made at least 2 attempts after that, during 2018, but the new administration never brought the approval motion to governance. Huh. Talk about amazing coincidences.
I see OSDI as in a coma. I'm it's caretaker. I felt it was important to refuse to be coerced into resigning from all governance, exec or non-technical matters in OSDI, or turned into an effective dictatorship, while they profited from the pretense of democracy.
Instead I repeatedly told them I would live with any outcome they could achieve via a democratic motion with the new administration. They wouldn't make a motion,.
if and when others, including platform adopters want to claim their equal vote, and move the spec forward according to the democratic processes everyone agreed to (and evolve them democratically as well), I'm happy to help with that transition.
joemcl
commented
3 years ago Thanks for the comment, Joe. Parsons seems great at first glance, and it does seem to be in the spirit of OSDI / share some of the same motivations. In terms of the actual product, it's very different (a python package in Parsons' case, an implementation-agnostic RESTful API standard in OSDI's case). Happy to chat about the possibilities for connecting Civi with various things over on the Civi Mattermost. Thanks for being an advisor on the previous OSDI-Civi project!
Thanks, yeah I'm aware they are different :) . Besides Action Network, there are other platforms that implemented parts of the OSDI standard, which is what I helped to recruit for awhile back. There is a link to those on the wiki here. But the real growth in connecting up a bunch of different platforms, practically speaking, over the last couple of years has been through the Parsons project.
highfalutin
commented
3 years ago I get what you're saying, @joemcl.
I want to acknowledge @joshco's comment which goes into a lot of history that I was unaware of. I'll just say I would celebrate the wider adoption of "democratically decided standards that create a level playing field for new entrants", whether that means OSDI coming out of its coma or something else. But my own role is very limited. I'm trying to build my little Civi extension so that it works with the Action Network API (that's the project that I was hired for) but is also flexible enough to be extended to other OSDI APIs if they come along. I think that's about all I can do for now.
joemcl
commented
3 years ago @highfalutin cool let's catch up at chat.civicrm.org, would love to hear more about your project.
joshco
commented
3 years ago @highfalutin Please make sure your work complies with the OSDI licenses. See the end of this comment.
@joemcl If you are going to make these assertions in front of the osdi repo audience, could you clarify what your statement means, here?
connecting up a bunch of different platforms, practically speaking
How does what you are asserting help hifalutin accomplish his task?
Sounds like the task is sending a Civi contact over to Action Network, maybe along with tags, signups etc. Is that right?
That's the most common integration scenario in the progressive tech ecosystem, and one of the first scenarios specified and prototyped in the OSDI specification. It fits the description of many of the integrations listed on Action Network's site, eg
Action takers on XYZ app will be subscribed to your Action Network email list, tagged correctly, and unsubscribed appropriately. [ In Action Network ]
That is Person Signup Helper: http://opensupporter.github.io/osdi-docs/person_signup.html
If you look at the source code for the Action Network Parson module, you'll see OSDI person signup helper as well. Yet Action Network misrepresents it as its own property.
(Assume we set aside the challenge of calling a python library from PHP, which Civi is written in)
What value does hifalutin or their customers get by calling proprietary APIs? That entrenches existing players. It creates barriers to new competition, increases costs for customers. And customers and entrepreneurs from marginalized communities with the fewest resources will feel that pain the most.
Why not just invoke OSDI person signup helper directly?
If some developers want a wrapper around the HTTP REST library, OSDI leverages the HAL ecosystem. There's the HAL browser console, which Action Network and most OSDI implementations use. There are HAL libraries for a variety of languages, including python So you're using a programming API that is the same calls regardless of which OSDI server you are using. http://opensupporter.github.io/osdi-docs/#working-with-osdi-in-real-life
Why should everyone else have to start over and re-invent these wheels while Action Network gets to exclusively profit from what we all contributed labor to build?
Hifalutin said:
but is also flexible enough to be extended to other OSDI APIs if they come along
There's no such thing as "other OSDI APIs" There is just the OSDI specification, and implementations of it. Action Network is an OSDI implementation.
What you may have meant was other platform side implementations of the OSDI spec.
Your extension can work with VAN's current OSDI implementation as well as Action Network. There is a Civi one Joe and I were using with the Spoke connector? That doesn't require any coding. There is Action Network, VAN. The Civi one needs some finishing, but with very little work, it could probably accept data from most of the apps on Action Network's integration page.
If and when PDI decides to implement, it will work with them too, and your extension wont require updates.
Your implementation should also work with NGPVAN's OSDI Service, which is another OSDI platform side implementation. https://osdi.ngpvan.com/browser/browser.html#/api/v1
It's odd that Action Network didn't mention NGPVAN's implementation to you, given they use it themselves to integrate with VAN. It supports another Helper scenario which is Record Attendance Helper. That signs a person up for an event.
Action Network's VAN Event sync feature uses this scenario. By integrating with VAN through the their OSDI service, as opposed to VAN's proprietary API, Action Network can use the same OSDI Events formats and REST operations they expose to integrator like you and others. less code. cheaper.
The sandbox is meant as a learning tool, and for testing apps by developers like yourself for a broader set of scenarios. It is also a platform implementation of OSDI, from an integration standpoint.
Tutorial: OSDI 101 Zero to Person Signup Helper tutorial.
@hifalitun Could you let me know where you encountered the api.opensupporter.org link so I can update it?
It might be useful to test your extension against the sandbox as a sanity check.
The code at api.opensupporter.org is like 7 years old. It was provided to Action Network as part of an implementer support package.
That server is a rails app with an OSDI implementation strategy using a 3rd party gem "roar". I wrote the glue code to connect it to the rails controllers, active model, and the routes for the OSDI collections and actions like signup. The point was to illustrate what a typical Rails app would need to add in order to implement OSDI.
Action Network is a Rails app. So they could include the gem, cut and paste the glue code, and have a basic implementation. Then they could tailor it to their application's nuances. They did.
Joe said:
there are other platforms that implemented parts of the OSDI standard Like Bluetooth Audio Profile, Bluetooth Keyboard Profile, et al, scope what parts of the spec are needed to accomplish a scenario. Ie perform something useful. OSDI has a similar scoping concept.
"Helpers" like person signup helper specify simple scenarios, Integration Profiles like Fundraising Profile specify more complicated ones. A given implementation will implement the helpers or profiles that correspond to the type of product and features it offers and avoid the ones it doesn't' need.
This is a plus, not a minus.
I founded OSDI after I worked as Director of Technology for the Washington State gay marriage campaign in 2012, where I ran in to the pain of integration with proprietary APIs in this ecosystem. Prior to that I worked in the tech world at Microsoft and others for 20 years. I've always had a specialization in doing standards work since the 1990s. As a beginner, the first standard I contributed to was HTTP/1.1 in the IETF.
Before Action Network joined OSDI in November 2013, it was provided with our goals and rules:
https://marriagehero.org/slides/2013_06_18_one-sheet.pdf
That mission was to create a single API for all platforms and apps to implement to reduce costs for customers. OSDI is for any app, and any platform. It was specifically to create a level playing field where products compete on their merits not their market share or scale of their ecosystem.
The organizational rules were defined as a democracy to ensure fairness and ensure that the work was focused on customers, rather than being used as a lever against their competitors.
https://marriagehero.org/slides/2013_08_01_osdi-governance.v3-approved.pdf
Though Action Network agreed to this mission and our rules, it had other plans.
Note that the license grants apply ONLY to implementations of the OSDI specification.
Please ensure that your extension is compliant with the OSDI intellectual property and copyright licenses here: https://github.com/opensupporter/osdi-docs/blob/gh-pages/license.md
That means
joemcl
commented
3 years ago @joshco Yes thank you so much for pointing out things that I'm aware of. This is not something I wanted to get into publicly, but you have decided to do so.
Without going into any detail, you and I are both well aware of the primary reason why OSDI has been stalled for the last couple / few years.
You decided a while ago that you did not want to separate the OSDI project and organization from yourself. They are definitely different things, but you can't separate them.
Unless and until you make a clean break from the OSDI project and the organization, such as it exists now, and I'm not sure that it does exist, I have little reason to believe that any additional organizations will implement any of the OSDI spec.
joshco
commented
3 years ago Umm. wow. Your statement can be interpreted two very different ways. So when you use that language, I just have to ask... Does "things that Joe is aware of" include the following facts and are the dots connecting ( i sent you an email with some diagrams rather than here)
I am not the one that connected those things. they did. What they did was extortion to get rid of a competitive obstacle, retaliate against protected behavior because they elevate gender above sexual orientation. That's against the law.
Unless and until you make a clear break from the OSDI project and the organization, such as it exists now, and I'm not sure that it does exist, I have little reason to believe that any additional organizations will implement any of the OSDI spec.
Who are these? If it's the oligarchs, explain to me what they did that helped the organization? This hostage-taking, coercion, retaliation, is a huge part of the problem OSDI was meant to solve. And much of their objection is a pretext just to prevent a democracy from taking hold,.
So if the other organizations you are referring to are beyond the oligarchs (AN, MoveOn), If it's companies that I haven't spoken with, why not ask them to talk with me?
Action Network states the goal of "1 of 2 widely adopted progressive APIs" in August 2014. That's when they were expecting to walk away with the OSDI spec in hand to use as their proprietary API.
That's painting a picture similar to mobile, dominated by Google Android and Apple iPhone, except it AN and VAN. Just the two of them at the top. That's using a standards effort to cheat, and rocket from new company to one of the two dominant players, then renaming the standard to use it as your proprietary API, and an unfair competitive advantage.
They also made sure they took control (via RagTag) to bolt the door shut and lock out PDI. once PDI got approved they would instantly have as much power as Action Network over the spec,. Then the game is over and it will be a level playing field.
I would think that PDI would be the next one to help get implemented. They got totally screwed. What happened with them? Did they implement? In early March 2018, they tried to join, the Acting Chair asked me for the process checklist and I gave it, but I never heard back. Things went crazy after. Do you know? I heard they were trying to hire someone to develop it.
joshco
commented
3 years ago You are aiding people who engaged in extortion after they were unable to get what they wanted by playing fair.. I am the one who is the victim of predatory behavior by people who joined under false pretenses and are now simply using power to get rid of the person most responsible for the value of the asset they have stolen.
There is no point to writing much else, because it is clear that this entire thread was a script to continue to damage this project, and engage in deception.
I'm done being treated like an animal and this never ending predatory behavior from Action Network's Director of Technology who can't handle the fact that he underestimated a gay male's proficiency, and needs to persistently regain his dominance by any abusive means necessary.
Since you continue to participate and enable it, aren't making any positive contribution,, you are banned until you are committed to changing your behavior and respecting all protected classes equally.
Hello, I'm currently working on an extension to CiviCRM which will allow for syncing with remote OSDI services. I have been doing some testing against http://api.opensupporter.org/hb2/browser.html.
When I make a PUT request to a person's endpoint, for example to add an address, the operation succeeds but the server returns a blank response. I'd expect to receive the person resource back -- see Scenario: Modifying a person (PUT)
Would it be possible to fix api.opensupporter.org so it returns the correct response to a PUT?
(Or is there another demo OSDI server that I could be testing against?)