Oh, sorry, I misread which half you were asking about.

Am I going crazy, or do those methods only handle the "blob fetching" part of this equation? I was looking for examples of the "create a File, do a chunked upload, attach said File to an existing object" flow.

Yeah, diffusion.rawdiffquery and diffusion.filecontentquery both do this.

For uploading binary blobs, we'd do the reverse: have the client stream the blob into Files, then call an API method with a reference to the object.

Deprecate conduit sessions and conduit.connect.
Support direct token-based auth (?token=abdef123) and make this the standard.

Support multiple request encodings (likely BSON, protobuf, or messagepack). Leave JSON as the default, but in cases where messages can not be represented in JSON this gives us a plausible way forward.

I don't believe there are remaining outstanding requests for this.

quack

• D20208 adds an authorPHIDs constraint.
• D20209 provides details for transactions which add or remove projects. See above for format and rationale, or just query something and see what pops out.
• D20211 makes the documentation less bare-bones.

Currently, project tag changes and subscriber changes don't expose data in "transaction.search" because there's no "obviously correct" way to represent these changes in a future-proof way.

To my surprise, it also seems the method does not output any project tag changes that happened on a task?

Thanks for the quick reply!
Haven't played with webhooks yet so I did not know/realize it's transaction PHIDs only - "PHID" sounded generic enough that I incorrectly expected any kinds of PHIDs to be accepted as input. So this task is somewhere between either "clarify documentation that only transaction PHIDs are supported" or a "support other PHIDs" low-prio enhancement request.

The phids constraints matches transactions with specific PHIDs (PHID-XACT-...). Usually, you'll have a list of transaction PHIDs when you're responding to a webhook callback, so the phids constraint is most useful for webhooks.

From T13222, this should also revisit MFA around Conduit tokens. In particular:

Hey guys,

@amckinley, for general context on where I'm headed here:

(Feature request with no support mana and no discussion.)

Even with OAuth, you still can't make AJAX requests to Conduit from client-side JavaScript, right? Is the idea that the backend code uses OAuth to talk to Conduit on a user's behalf?

Plans, yes. Timing is trickier. Currently, we only have one outstanding request for this feature (PHI760, which mostly wants project.search). So it's in queue somewhere, but currently beyond the forecasting horizon.

@epriestley any timing/plans for expanding? Would love to replace our older user token flows with an OAuth flow. We'd need a few other methods though:

Conduit API methods define a getRequiredScope() method, which tells you the scope they require.

Are there any obvious ways to see scope requirements/availability today, even if it means spelunking into the source code?

I think that's pretty much everything. There will be a little followup work in T10883 and maybe T13076 / T13120.

Everything here should pretty much work except:

Before I can get rid of AlmanacDeviceTransaction::TYPE_INTERFACE, we have two meaningful callsites in rSERVICES and one unit test in rSAAS to clean up.

There's a bit of a mess with AlmanacInterface and AlmanacDevice. Currently, AlmanacInterface does not use transactions, and is edited purely as a side effect of INTERFACE transactions applying to AlmanacDevice. I'm going to change how this works so that AlmanacInterface is a normal transactional object and can use the same rules and infrastructure as everything else.

Hi @tappers, I can't get your query flow to work on my machine, would it be possible for you to give me a simple example of a working query ?

It's also possible to write a custom instances.do-exactly-what-we-need sort of endpoint and generalize later if that seems like a more promising approach.

The other shadow lurking in the water here -- which I think we can mostly avoid -- is that Almanac is mostly a-bit-bare-bones-but-overall-pretty-functional, except that the way properties on Bindings and Services are specified and edited is complete garbage. You more or less just have to magically know which properties are valid, and there's no real support for defaults or nice UI controls or hints about what you can set or suggestions that you're making stuff up and probably typo'd something.

The "most right" way in terms of consistency is to fully convert Binding to EditEngine, then implement almanac.binding.edit which can create/edit bindings. When creating a binding, it would require transactions specifying the service and interface. PhamePostBlogTransaction is sort of an example of this: when you create a new post with phame.post.edit, you must specify a blog transaction.

What's the best way to add API endpoints for resources like bindings? Call it almanac.create_binding and have it take a service and an interface as arguments?