You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hive accounts can "delegate" posting authority to another account.
If 'podping_hivewriter' is running with account 'podping.cloud' it normally sends all podping custom_json from that account using the 'posting key' for that account.
If another Hive account (for example a podcast hosting company) were to have their own Hive account with its own unique keys. That account can grant or "delegate" posting authority to 'podping.cloud'. Once this has been done, 'podping.cloud' can send out podpings in the name of the hosting company. This also means the hosting company can contribute to the resource costs (by holding a small amount of Hive Power on their own account).
At this time, while we are upgrading the input system to include Medium and Reason codes, adding a simple 16 char string for another Hive account name is simple.
Note: delegated authority means no keys or anything secret needs to be passed. The authorization to make this work happens outside of Hivewriter but could easily be handled via a simple web interface on podping.cloud.
The text was updated successfully, but these errors were encountered:
brianoflondon
changed the title
Allow for Hivewriter to accept an optional Hive account by ZMQ (passed with as Medium and Reason codes)
Allow for Hivewriter to accept an optional Hive account by ZMQ (passed alongside Medium and Reason codes)
Oct 19, 2022
Just to add something here: this can and probably should be done by podping.cloud.
You have a mapping for the API key which sends the ping in, that can be mapped to a Hive account. I would then propose to run all the HiveWriters for Podping.cloud under one Hive name (probably podping.cloud which I've obviously reserved) and then the actual Pings would be sent out by podping.blubrry or podping.rss or whatever.
We can create and hold those accounts or if any of the hosting co's are interested they can make their own accounts and hold the keys. The beauty is that we can send pings on their account, once they've clicked a simple web ui and delegated posting authority to podping.cloud.
This is a longer term plan and no rush.
I brought it up now because the kinds of queues we need are similar to what Alecks is doing for Medium and Reason.
Hive accounts can "delegate" posting authority to another account.
If 'podping_hivewriter' is running with account 'podping.cloud' it normally sends all podping custom_json from that account using the 'posting key' for that account.
If another Hive account (for example a podcast hosting company) were to have their own Hive account with its own unique keys. That account can grant or "delegate" posting authority to 'podping.cloud'. Once this has been done, 'podping.cloud' can send out podpings in the name of the hosting company. This also means the hosting company can contribute to the resource costs (by holding a small amount of Hive Power on their own account).
At this time, while we are upgrading the input system to include Medium and Reason codes, adding a simple 16 char string for another Hive account name is simple.
Note: delegated authority means no keys or anything secret needs to be passed. The authorization to make this work happens outside of Hivewriter but could easily be handled via a simple web interface on podping.cloud.
The text was updated successfully, but these errors were encountered: