CIP0006 Stake pool extended metadata

Initial proposal for extended metadata that can be a basis for dialog

is really good idea have there email contacts (abuse+support)

Abuse contact information is a historically grown form and method for quick urgency communication between decentralized and often before unknown entities. So it sounds also appropriate as an optional but recommended contact information, based on a very common and diffused contact medium: E-mail
Examples
https://www.ripe.net/support/abuse
https://www.apnic.net/manage-ip/using-whois/abuse-and-spamming/
https://support.google.com/domains/answer/6022413?hl=en
https://en.wikipedia.org/wiki/SOA_record#Background
also email abuse reports already have some standardized format
https://en.wikipedia.org/wiki/Abuse_Reporting_Format

missing "telegram-admin-handle" (array) - on the one hand, it can replace the previous problem + we can connect bots with this handle as verified pool-admin, notifications only for pool-verified-telegram-admins and so.

Sure, I didn't understand the purpose of that or how it was different from the marketing accounts.  makes sense to me to add that back in.

I don't quite understand "pools" and combination with saturated_recommend; i mean [root][pools][...] is great okay, but saturated_recommend array should be in [root][saturated_recommend] (pool-ids of friends/owns pool which are recommended, when main pool is saturated)

The "recommend if full" idea is a good concept, but I'm unclear how best to implement this in practice and it brings up some strategic questions.
Is extended metadata meant to be different for each pool registered on chain?  or is the concept to have one extended metadata file for each pool you have registered.  It seems like your metadata concept was allowing multiple pools to share the same extended metadata so I headed down that path.  I think we all have to agree on this fundamental question first before we sort out the rest.

missing "telegram-admin-handle" (array) - on the one hand, it can replace the previous problem + we can connect bots with this handle as verified pool-admin, notifications only for pool-verified-telegram-admins and so.

Sure, I didn't understand the purpose of that or how it was different from the marketing accounts. makes sense to me to add that back in.

I don't quite understand "pools" and combination with saturated_recommend; i mean [root][pools][...] is great okay, but saturated_recommend array should be in [root][saturated_recommend] (pool-ids of friends/owns pool which are recommended, when main pool is saturated)

The "recommend if full" idea is a good concept, but I'm unclear how best to implement this in practice and it brings up some strategic questions.
Is extended metadata meant to be different for each pool registered on chain? or is the concept to have one extended metadata file for each pool you have registered. It seems like your metadata concept was allowing multiple pools to share the same extended metadata so I headed down that path. I think we all have to agree on this fundamental question first before we sort out the rest.

Thank you. Extended is ideally unique for every pool (that was plan), like basic meta.json. Is true, someone can use one extended for more than one pool, but main target is 1=1.
I can imagine that in time we will come up with something new here that will already strictly require 1 = 1.

@gufmar yes, abuse is great use-case for a lot of services (for. ex. when you are sending spams, when you have attacking script / backdoor on webhosting, when your client does something he doesn't, something illegal for removal...), but here in this case I just do not see a specific use. Do we have a specific case where it would really make sense more than, for example, an official iohk newsletter?

abuse is great use-case for a lot of services (for. ex. when you are sending spams, when you have attacking script / backdoor on webhosting, when your client does something he doesn't, something illegal for removal...), ... an official iohk newsletter?

we should define the intention and use case for abuse contacts.
I would not like to see it used as usual info addresses, nor for newsletters, marketing, promotion, campaigns...
In any case it's an optional (especially a correct working e-mail address) and when provided it should allow some urgent messaging because something unexpected/unwanted happened, from the senders point of view.

Thank you. Extended is ideally unique for every pool (that was plan), like basic meta.json. Is true, someone can use one extended for more than one pool, but main target is 1=1.
I can imagine that in time we will come up with something new here that will already strictly require 1 = 1.

Ok, I would recommend that we keep it 1 = 1 for now then.   The specific pool attributes would make more sense then inside the info category in my opinion, but it seems like you think pool should be a root attribute so how about something like this:
{
    "serial":<PHONE_NUMBER>,
    "itn": { ... },
    "info": { ... },
    "pool": {
            "id": "0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f",
            "country": "UK",
            "os": "LINUX",
            "infrastructure": "AWS",
            "status": "act",
            "my_other_pools":["0a0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f"],
            "saturated_recommend":["0a0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f"]
      }

}

I'd prefer not to do this as I think its confusing, but could also change
"pool":{ ... }

to
"pool":[{ ... }]

if we wanted to build in support for multiple pools from the start.

@papacarp it is true that since PoolTool does not anymore provide a link to inicial metadata JSON file it is hard to verify root of trust chain -> metadata -> extended metadata, before when you could click on a link that pointed to the on-chain registered metadata file, you could verify e.q. that both metadata and extended metadata live on a same domain with the same TLS certificate, this is not possible on PoolTool and I am not sure it was ever available on ADA Pools.
With that said, when using site such as PoolTool or ADA Pools, you are explicitly trusting a centralized counterparty to safely retrieve, process and display the embeded metadata, however there should probably be a recommendations on secure retieval and processing of extended metadata including e.q. how often are the data consumers expected to update such metadata.

Is the extra level of indirection deliberate to avoid having to re-register the pool? Or is it because you think you cannot put more data into the on-chain referenced metadata?

Yes, that is the main purpose of the creation this

It is unclear to me what the security model is here.

to be defined (or redefined)

With the on-chain referenced metadata, the checksum is on chain and signed by the pool operator and owners. So we know the metadata has not been tampered with and that they endorse the metadata content.

another variant by keeping the whole metadata secure verifiable and trustworthy is to not have any checksum on chain, but adding a signed witness to the metadata file. then the pool owner can alter the metadata file whenever he want without adding any load to the chain.
Might only require a serial field in the metadata file similar to DNS zone root files (YYYYMMDDxx) in order to make it easier for applications to detect updates.
If we can redefine the security model this way, I see no benefit in splitting up metadata in one signed and one linked only file.

With the current proposed extended metadata, ... we loose the tamper-resistance and loose assurance that the metadata content is endorsed by the operator or owners. We know they point to a URL but there are many points of weakness (like DNS hijacking, proxy or origin server hacking) so it's hard to trust the content.

the mentioned weaknesses seem putting in question more than half of the existing internet I would say. As it is already an existing requirement to provide the metadata.json over HTTPS only, same should be obligatory for an extended file of course. Might - as an additional requirement - it even needs to be the same hostname as the main metadata file, but as the linked extended URL is signed by the pool owner it should be safe to trust.  Then DNS- and Proxy-based MITM attacks are the challenge for an attacker, in order to modify the extended data like twitter handle or the owner logo (nothing fund or delegation related)

If we want the same security model as the on-chain referenced metadata, but for performance or other reasons want to have more data in a separate file, we can just use the same trick of a URL + content hash.

Can you explain please?
From my understanding if I modify the extended file, I need to update the hash in the main metadata file, and then I also need to re-register with an updated metadata hash on chain.

So I'm not asking for any specific design: you propose what you want to propose. I'm asking for these security questions to be addressed in the proposal.

definitively as it's important.
So in order to keep the whole resulting constellation as less complex as possible, I wonder first if there is any KO reason to not have the signed witness inside the metadata file, verifiable with the public owner key stored on-chain?
If there is a good technical/security reason, we should think about the pros/cons of having partial data in a more trustable main metadata and additional fields in a little bit less trustable file, not requiring re-registration. In this case we can also define what additional fields should become part of the main metadata file (same as the existing homepage URL) and what
can stay in the extended file.
Also, keep in mind any linked resource file like png, svg, ... has the same security model related questions. So if our conclusion is all in one metadata file with signed witness or on-chain hash, then all additional such resource files, will not be possible.

I wonder first if there is any KO reason to not have the signed witness inside the metadata file, verifiable with the public owner key stored on-chain?

Not a KO, but it is susceptible to version downgrade / rollback / replay for anyone bootstraping his / her app from chain genesis and fetching metadata as pool certificates go on the chain.

In preparation for our meeting in a few hours I've updated.  There are a few conversations I'm hoping we can close out during our meeting:

Security Model:  As per @dcoutts request to clarify, we are proposing a model that does NOT require an update to the on chain registration currently.  It seems like we should have a conversation together about whether this is the right strategy.

If security is required then we could expand the max size of the on chain data, or use the witness strategy to validate the extended json.  If security is not required we can simply include a link to extended metadata from the on chain registration.

We have an open dialog still about whether abuse email contacts in the metadata are useful

The structure of the JSON is a little arbitrary as it started with the adapools.org implementation.  I tried to incorporate existing keys and hierarchy as much as possible although from a green field perspective I'm not sure I would have implemented that way.     However, in the interest of bringing this to closure I think the proposed hierarchy is adequate.

Why is gender (sex) of the operator included at all?
Seems like personally identifying information like that should go in the about me secion and be completely optional.

I just read this proposal in detail and have a few comments, questions and suggestions.

Restructure the content to more clearly show what attributes belong to what objects. Main objects being pool, operator and owner.  See example.
Drop "itn" section. Seems like irrelevant history.
Change CI to "media_assets".
Rename media assets to have consistent naming scheme.
Replace "color_main" with "color_fg" and "color_bg".
Remove redundant "_handle" from all social attributes.
For "social" how will new platforms be added?
"contact" mixes types of comms ("abuse" and "support" with channels of comms "telegram_admin".

If the idea of having the address for a company is to have a mailing address or locate it on a map, it seems you might need "state_or_region" and "postal_code".
Is "company_id" and "vat_id" something potentially used for tax purposes or government verification?
"about" is an unnecessary layer where the attributes should be placed under the appropriate top level objects instead.
How do you add to the list of "os" and "infrastructure" values?
"infrastructure" mixes types of infrastructure with vendors.
Why are status values only 3 letters? Why not "active" instead of "act"?
Are all elements optional except "serial"?
I don't understand the difference between "telegram_handle" and "telegram_admin".  What about adding "telegram_channel"?
I think it would be good to add "primary" to contact so you know which channel is the desired primary contact method.
How about adding "phone_call" and "phone_text" to "contact"?
Spell out "address" instead of "addr".
I think we need to decide whether including personally identifying traits like "gender" is desirable. They can be used to promote or discriminate. If we want them then why not add others like "ethnicity"?
"gender" should be spelled out as "female", "male" or "other".
I would change "team_affiliation" to "affiliations" since they may not be teams.
If we have "affiliations" why not add "supporting" since that is currently a distinguishing factor for many pools.
Maybe "owner" should be an array of "owners".
Add multiple countries for node locations.
Change "saturated_recommend" to "saturated_recommend_id" because we may want to add "saturated_recommend_ticker" or "saturated_recommend_portfolio" later.

This turned out to be a lot but I hope it is helpful.
If people like this overall, I can help update the schema if desired.
Example

{
    "serial":<PHONE_NUMBER>,
    "pool": {
        "id": "0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f",
        "status": "active",
        "saturated_recommend_id":"0a0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f",
        "contact": {
            "primary": "email",
            "discord": "coolpool",
            "email"<EMAIL_ADDRESS>            "facebook": "coolpool",
            "github": "coolpool",
            "phone_call": "+44 123456789",
            "phone_text": "+44 123456789",
            "rss": "https://mycoolpool.com/xml/poolrss.xml",
            "telegram": "coolpool",
            "telegram_channel":"https://t.me/coolchannel",
            "twitch": "coolpool",
            "twitter": "coolpool",
            "youtube": "coolpool"
        },
        "technology": {
            "description": "We have a high availability setup with 2 block producers and 4 relays in 2 different data centers.",
            "os": "Linux",
            "infrastructure": "cloud",
            "node_countries": [
                "DE",
                "UK"
            ]
        },
        "media_assets": {
            "icon_png_64x64_url": "https://mycoolpool.com/icon.png",
            "logo_png_url": "https://mycoolpool.com/logo.png",
            "logo_svg_url": "https://mycoolpool.com/logo.svg",
            "color_fg": "#RRGGBB",
            "color_bg": "#RRGGBB"
        },
        "affiliations": [
            "ISPPA",
            "Cardano Ambassador"
        ],
        "supporting": [
            "10% of fees donated to Save the Frogs.",
            "Some proceeds used to sponsor local Cardano meetup."
        ]
    },
    "operator": {
        "description": "Cool Ops operates pools for people.",
        "name": "Juanita Lopez",
        "company_name": "Cool Ops LLC",
        "company_id": "123456789",
        "vat_id": "GB123456789",
        "address": "101 Main St., Apt. 3",
        "city": "London",
        "state_or_region": "",
        "country": "UK",
        "postal_code": "123456",
        "gender": "",
        "ethnicity": ""
    },
    "owner": {
        "description": "I am a podcaster and believer in Cardano.",
        "name": "Ramesh Patel",
        "company_name": "",
        "company_id": "",
        "vat_id": "",
        "address": "",
        "city": "Vancouver",
        "state_or_region": "BC",
        "country": "CA",
        "postal_code": "12345",
        "gender": "male",
        "ethnicity": "Indian"
    }
}

Wow, thank you for your thoughtful feedback.  I generally have no problem with the structure you propose.  As mentioned earlier, the structure I put in was evolved from the adapools implementation in an attempt to make this all as easy as possible.  I'd be fine switching to your structure if we can all agree.

Drop "itn" section. Seems like irrelevant history.

It does not seem irrelevant yet.  We are still at 50% staked in Cardano, so that's a lot of stake still looking for homes.

For "social" how will new platforms be added?

I assume another CIP?

If the idea of having the address for a company is to have a mailing address or locate it on a map, it seems you might need "state_or_region" and "postal_code".

My goal was simply a region defined by an internationally recognized country code.  The address details came from adapools.

Is "company_id" and "vat_id" something potentially used for tax purposes or government verification?

adapools added that.  I'm not sure where they were going with it.

How do you add to the list of "os" and "infrastructure" values?

I assume another CIP.  I'm not sure how the process would work for lookup details like that.

"infrastructure" mixes types of infrastructure with vendors.

Feel free to create a better list.  These are the lists we used in pooltool.

Why are status values only 3 letters? Why not "active" instead of "act"?

Its arbitrary.  If you think it makes more sense as active then go for it.  I envision these will end up translated so wanted a code to abstract a bit from the word.

Are all elements optional except "serial"?

Seems like it.  If you add a pool, then the pool ID is required, but I could envision someone wanting to "erase" all metadata and they could do so by submitting an empty extended json with a new serial.

I don't understand the difference between "telegram_handle" and "telegram_admin".  What about adding "telegram_channel"?

again, adapools.  I'm fine with those changes.  I know telegram_admin is referring to a private, direct, contact point wheras telegram_handle is likey a public one or more specifically a channel as you point out.

I think we need to decide whether including personally identifying traits like "gender" is desirable. They can be used to promote or discriminate. If we want them then why not add others like "ethnicity"?

Well I think its an important distinguishing strategy for pools that we should capture IF the pool wants to market themselves that way.  I also know CF has placed an emphasis on promoting gender in blockchain.  Ethnicity would be the same, and leaving it out was not so much an oversight as just a decision to keep this incremental.    Feel free to add in ethnicity if you can find a standard designator set for them (IEC? ISO?)

"gender" should be spelled out as "female", "male" or "other".

we used a the ISO standard for this.  Since gender identity has evolved considerably over the last 20 years I think its best to just allow the standards bodies to create the identifiers and we just follow that.  Look up ISO/IEC 5218 sex

Add multiple countries for node locations.

in pooltool we gave you two options.  owner location and server location.  Many of us have nodes spread all over the world and the public facing ones are often registered and easily traceable.  Again, the goal here is to give the operators a country to affiliate with not necessarily document or capture reality.  So I'm fine if you want to make the nodes an array, but it wasn't really my intention in capturing the data.

This turned out to be a lot but I hope it is helpful.

Its very helpful.  I really appreciate your thoughtful ideas and practical recommendations.

If people like this overall, I can help update the schema if desired.

That would be great!  I commented on the changes I had feedback on above.  If I didn't comment on it, then I'm fine with your recommendation.  My goal is not so much to control this standard, but to have something in place so we can start sharing data.

2. Drop "itn" section. Seems like irrelevant history.

First, thank you for this feedback. I believe this also makes evident how and why CIP efforts can help to end up with better, combined results.
The ITN section might seem irrelevant, but often the desired effect is invisible. In this case this ITN ticker proof has (and still does) prevent from imitating duplicates. At least I'm not aware of any duplicate tickers for all those who published their itn proof.

Thanks for clarifying those points.
Regarding ethnicity, I did not find any international standard.
I did find a list on wikipedia but it is dynamic and would be a lot to encode.
I think we can leave ethnicity as something that people can put in their description if they want.
I think both "operator" and "owner" could have the info separated into "person" and "organization".  You could have either or both.
"person" is the human point of contact and "organization" is the company or group.
Here is an updated example:

{
    "serial":<PHONE_NUMBER>,
    "pool": {
        "id": "0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f",
        "country": "DE",
        "status": "act",
        "saturated_recommend_id":"0a0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f",
        "contact": {
            "primary": "email",
            "discord": "coolpool",
            "email"<EMAIL_ADDRESS>            "facebook": "coolpool",
            "github": "coolpool",
            "phone_call": "+44 123456789",
            "phone_text": "+44 123456789",
            "rss": "https://mycoolpool.com/xml/poolrss.xml",
            "telegram": "coolpool",
            "telegram_channel":"https://t.me/coolchannel",
            "twitch": "coolpool",
            "twitter": "coolpool",
            "youtube": "coolpool"
        },
        "technology": {
            "description": "We have a high availability setup with 2 block producers and 4 relays in 2 different data centers.",
            "os": "Linux",
            "infrastructure": "cloud"
        },
        "media_assets": {
            "icon_png_64x64": "https://mycoolpool.com/icon.png",
            "logo_png": "https://mycoolpool.com/logo.png",
            "logo_svg": "https://mycoolpool.com/logo.svg",
            "color_fg": "#RRGGBB",
            "color_bg": "#RRGGBB"
        },
        "affiliations": [
            "ISPPA",
            "Cardano Ambassador"
        ],
        "supporting": [
            "10% of fees donated to Save the Frogs.",
            "Some proceeds used to sponsor local Cardano meetup."
        ],
        "itn": {
            "owner": "ed25519_pk1...",
            "witness": "ed25519_sig1..."
        }
    },
    "operator": {
        "description": "Cool Ops operates pools for people.",
        "person": {
            "name": "Juanita Lopez",
            "address": "101 Main St., Suite 3",
            "city": "London",
            "state_or_region": "",
            "postal_code": "123456",
            "country": "UK",
            "gender": "2"
        ],
        "organization": {
            "name": "Cool Ops LLC",
            "government_id": "123456789",
            "vat_id": "GB123456789",
            "address": "101 Main St.",
            "city": "London",
            "state_or_region": "",
            "postal_code": "123456",
            "country": "UK"
        ]
    },
    "owner": {
        "description": "I am a podcaster and believer in Cardano.",
        "person": {
            "name": "Ramesh Patel",
            "address": "",
            "city": "Vancouver",
            "state_or_region": "BC",
            "postal_code": "",
            "country": "CA",
            "gender": "1"
        ]
    }
}

A couple questions about the lists like "os" and "infrastructure".

It looks like the schema has the values as examples. Does that mean people can put whatever they want? For example, can I put "Ubuntu", "OpenVMS", or "secret message here"? Does the "$id" value of "...anyOf..." limit the choice?
Are the values all caps for a reason?
Sorry for naive questions, I have only written schemas for xml and databases and the json schema is new to me.

For the "os" and "infrastructure" lists I would suggest:

"os": {
    "$id": "#/properties/pools/items/anyOf/0/properties/os",
    "type": "string",
    "title": "Pool Operating System",
    "description": "Pool Operating System",
    "default": "",
    "examples": [
        "Linux",
        "macOS",
        "Windows",
        "BSD",
        "Other",
        "Undisclosed"
    ]
},

"infrastructure": {
    "$id": "#/properties/pools/items/anyOf/0/properties/infrastructure",
    "type": "string",
    "title": "Pool Infrastructure",
    "description": "Pool infrastructure Platform",
    "default": "",
    "examples": [
        "cloud",
        "hosted bare metal",
        "local bare metal",
        "other",
        "undisclosed"
    ]
},

I haven't seen any response to my latest proposals and questions on this.
Does that indicate general acceptance or everyone too busy?

Hi Shawn,
Everyone busy is likely right: We get to dig into it further throughout the
meeting - it often takes getting everyone in the same meeting to focus...
Everyone has a different area they are already working on, so "something"
pulling from the side is tough. This is the part where we're hoping to
bring in Editors from the community to step in, but since the project has
been mostly built in-house (IOG) it's not easy to get external expert
opinions.
Thanks for your patience, and/or comments in there.
Frederic
On Tue, Sep 22, 2020 at 3:49 AM Shawn McMurdo<EMAIL_ADDRESS>wrote:

I haven't seen any response to my latest proposals and questions on this.
Does that indicate general acceptance or everyone too busy?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cardano-foundation/CIPs/pull/15#issuecomment-696455942,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOA6WTUPY4BEJQPOXK7RI3TSG7YB5ANCNFSM4QIDHHEQ
.

--
Frederic Johnson
Technical Project Manager | Cardano Foundation | TW
https://twitter.com/ACryptoMuppet | TG https://t.me/acryptomuppet
Website: www.cardanofoundation.org

@papacarp - post-Editors meeting we hope you get to add changes as desired in the PR (in the next two weeks would be great!), we'd like to formally move into draft once that happens.
@gufmar - any outcome re: outreach to stakepools?

I agree with all changes, thanks to all.
From my view only:

|  extended | A url for extended metadata| Optional, 64 Characters Maximum, must be a valid URL |

Please extend this to 128 Characters Max, I believe we really dont want have there another redirect-mania, 128 should be okay for github raws etc.

@papacarp can you please rename the PR to reflect what is the CIP about?

Please extend this to 128 Characters Max, I believe we really dont want have there another redirect-mania, 128 should be okay for github raws etc.

we need two URLs (data and hash file)
it shouldn't be a problem to allow up to 128 bytes
but then it makes sense to increase the max size of the main metadata file to 1024 bytes

@cardanians @papacarp @SebastienGllmt @ashisherc @dmitrystas
based on the CIP-Editor call conversations, I'm going to refine the proposal.
One question towards known metadata consumers (portal operators) is about the absolutely required fields.
This CIPs initial extended metadata should include what we know is required and will effectively be used by SPOs, not more.
The current state of the proposed JSON structure is
{
	"serial":<PHONE_NUMBER>,
	"pool": {
		"id": "0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f",
		"country": "DE",
		"status": "act",
		"saturated_recommend_id": "0a0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f",
		"contact": {
			"primary": "email",
			"discord": "coolpool",
			"email"<EMAIL_ADDRESS>			"facebook": "coolpool",
			"github": "coolpool",
			"phone_call": "+44 123456789",
			"phone_text": "+44 123456789",
			"feed": "https://mycoolpool.com/xml/poolrss.xml",
			"telegram": "coolpool",
			"telegram_channel": "https://t.me/coolchannel",
			"twitch": "coolpool",
			"twitter": "coolpool",
			"youtube": "coolpool"
		},
		"technology": {
			"description": "We have a high availability setup with 2 block producers and 4 relays in 2 different data centers.",
			"os": {
				"$id": "#/properties/pools/items/anyOf/0/properties/os",
				"type": "string",
				"title": "Pool Operating System",
				"description": "Pool Operating System",
				"default": "",
				"examples": [
					"Linux",
					"macOS",
					"Windows",
					"BSD",
					"Other",
					"Undisclosed"
				]
			},
			"infrastructure": {
				"$id": "#/properties/pools/items/anyOf/0/properties/infrastructure",
				"type": "string",
				"title": "Pool Infrastructure",
				"description": "Pool infrastructure Platform",
				"default": "",
				"examples": [
					"cloud",
					"hosted bare metal",
					"local bare metal",
					"other",
					"undisclosed"
				]
			}
		},
		"media_assets": {
			"icon_png_64x64": "https://mycoolpool.com/icon.png",
			"logo_png": "https://mycoolpool.com/logo.png",
			"logo_svg": "https://mycoolpool.com/logo.svg",
			"color_fg": "#RRGGBB",
			"color_bg": "#RRGGBB"
		},
		"affiliations": [
			"ISPPA",
			"Cardano Ambassador"
		],
		"supporting": [
			"10% of fees donated to Save the Frogs.",
			"Some proceeds used to sponsor local Cardano meetup."
		],
		"itn": {
			"owner": "ed25519_pk1...",
			"witness": "ed25519_sig1..."
		}
	},
	"operator": {
		"description": "Cool Ops operates pools for people.",
		"person": {
			"name": "Juanita Lopez",
			"address": "101 Main St., Suite 3",
			"city": "London",
			"state_or_region": "",
			"postal_code": "123456",
			"country": "UK",
			"gender": "2"
		},
		"organization": {
			"name": "Cool Ops LLC",
			"government_id": "123456789",
			"vat_id": "GB123456789",
			"address": "101 Main St.",
			"city": "London",
			"state_or_region": "",
			"postal_code": "123456",
			"country": "UK"
		}
	},
	"owner": {
		"description": "I am a podcaster and believer in Cardano.",
		"person": {
			"name": "Ramesh Patel",
			"address": "",
			"city": "Vancouver",
			"state_or_region": "BC",
			"postal_code": "",
			"country": "CA",
			"gender": "1"
		}
	}
}

A second question is related to the RRS feed technology.
@mmahut brought up if RRS-feeds, as proposed by @dcoutts, are still commonly used, or if we can look into something else (see https://github.com/cardano-foundation/CIPs/pull/15#discussion_r519034473)
some thoughts on required fields and potential risks
I wonder if we really want to have complete postal addresses of operators and owners. In my opinion this is even a security risk. (where are the keys?)
Do we need a pool.country field in addition to owner.person and operator.organisation ?  In the meaning of do we want to see claims like owner from London UK and operator from Amsterdam NL define their Pool is located in Ghana Africa?
Generally I see 3 category of "claims" an SPO can make here

pool.id or pool.contact.telegram or pool.media_assets.logo_png  Here it is in the full interest of SPOs to set the right values.
pool.technology.description is not verifiable as literally any text. There is no other way, but the consumer of this information also understands that it is a subjective claim of the SPO.
I believe we should think twice what can go wrong with the remaining fields such as pool.technology.os or pool.supporting or pool.country  because the consumer might see this as reliable and verified information, while the SPO can claim literally anything here.

Folks, can we please concentrate on the mechanism for the extended metadata, and postpone all the bikeshedding about the content of the extended metadata for later?
The mechanism is what needs to be carefully described and agreed for us to be able to implement anything. Once we have that in place we can discuss additions to the schema with relatively little technical risk. Any time we spend now on the schema delays getting the mechanism in place.
So I'd again recommend that we go with a absolutely minimal metadata schema (e.g. with one single example uncontroversial entry), and firm up the description of the mechanism for the extended metadata. Once that's agreed we can open the door to bikeshedding about what new metadata we want to add, and that can be done bit by bit, one thing at a time so we don't have to have uncontroversial items block on controversial items.

Folks, can we please concentrate on the mechanism for the extended metadata, and postpone all the bikeshedding about the content of the extended metadata for later?

My recent commit b53da370108a8fde1b13dd4e1abb61e37b109e60 describes one possible mechanism. it actually seems to need a small extension of the cli tool to calculate the signature of any json schema. Or we have to build the schema in a similar way as the current signature commands already expect.
There would be an alternative way for the signature by using TX metadata. The drawback is, a consumer would need a fully synched chain and probably a proper db-sync instance to have access to this validation data. On the other hand, it would be an elegant technique using the chain itself. We could even think about designing the whole thing according to the current DID design (https://www.w3.org/TR/did-core/)
Based on the feedback I have received from who is already using the existing, non-standardised extended metadata, I see the need to already include the most frequently used fields (e.g. logo, contact handles) in order to encourage rapid and significant adoption.

Todo:
add a step-by-step description on how a 3rd party can implement the pk/signature verification

In my opinion, what is missing from the proposed extended metadata specification is a way to specify the fingerprint of a public PGP key, or alternatively a download URL for the public key. Something like this:
{
    "email_pgp_key_fingerprint": "EDBB2C22DA2BC47A4B5D94EDD8EB88D3167C82B8",
    "email_pgp_key_url": "https://keys.openpgp.org/vks/v1/by-fingerprint/EDBB2C22DA2BC47A4B5D94EDD8EB88D3167C82B8"
}


Installation instructions

Sorry for being a complete nubbin, but the instructions (readme) don't actually show how to install this library in you project. I'm confused when downloading the latest version which folder I should put where in my project in Android Studio.
I've added plenty of .Lib libraries, so I'm familiar with that, but could you explain more explicitly, what need to go where in the ReadMe please?
It'll be one of those things that is probably an 'ahhh yes, obviously' kind of moments.
Many thanks in advance!

The Gradle dependency is used in Android Studio:
https://github.com/afollestad/material-dialogs#gradle-dependency-jcenter

I think you're assuming people like me, know as much as people like you. and you are missing a big problem for new devs who want to use your library...like me :)
I understand that I have to add the dependency to Gradle (same as a .Lib file)
The question is when I download your source file from here, it looks like this:
\material-dialogs-<IP_ADDRESS>\material-dialogs-<IP_ADDRESS>\

Which folder do I put where in my project?
What's the hierarchy?
Thanks again.

You don't download the source at all. You place the string you see in the README inside build.gradle of your app.
You may wanna look into how Gradle works, this will only work in Android Studio, also. If you're using Eclipse, it requires extra steps since it's no longer Google's official Android IDE.

Similar to this

Nope, I'm using Android Studio.
I see, so it will download the library for me?
Where does it store it in Android Studio?
Just reading through this to get an idea of Gradle:
http://igorpopov.io/2014/05/01/understanding-gradle/
Thanks for your patience.

Sorry, this isn't the best place to learn how Android Studio works. I'm a busy college student.
But yeah, Android Studio will download all of your library dependencies, where doesn't really matter. They're automatically made available in your project.
If you want to look at the library code and run the sample, then you can download the entire project and import it as a Gradle project. But if you're referencing just the library, copying and pasting that line and syncing your project is all that's needed.

I appreciate the help you have given so far, so many thanks.
I'm actually making progress now. Looking through your issues, it appears I have a similar situation to another user, where my project was imported into Android Studio and originally using Maven, not  jcenter().
So I'm going to work through solving that, and hopefully it'll all start working.
Thanks again.

Got it working.
changed to jCenter in build.gradle from Maven.
Downloaded latest build tools and sdk using sdk manager.
Thanks again, for this great library!

Good to hear, no problem!


edgex: upgrade edgex lib version and go version

@ngjaying @EMQmyd Please upgrade your local GO version to 1.15...

@jinfahua
The specific version of goang:1.5 is 1.15.2 instead of 1.15.1, and the version number of golang:1.5 will be updated with the update of golang, is this okay?

@jinfahua
The specific version of goang:1.5 is 1.15.2 instead of 1.15.1, and the version number of golang:1.5 will be updated with the update of golang, is this okay?

I suppose goang:1.5 should be ``goang:1.15? So I would suggest to use the specific version # 1.15.1`.


Adding Clickable Event to Cell

We have a requirement to add a link to the column data.

Please find the pull request 'Added clickable event to the Cell' to have this functionality.

Fixed in 9e6709c
cc/ @arcpato


Use readOnlyRootFilesystem securityContext in data plane pods

This intends to fix access-control-security-context-read-only-file-system certsuite test for data plane pods, since this has to fail in controller-manager pods because they require it for reconciliation loop.

from change #96:

FAILURE https://www.distributed-ci.io/jobs/6c0005da-7148-4cea-aa6a-206ea89a94e8/jobStates

Up to now, testpmd is working but trex is failing. By checking the logs, I've seen the same issue I saw in testpmd logs, complaining about /var/run/dpdk folder:
+ ./_t-rex-64 --cfg /usr/local/bin/example-cnf/trex_cfg.yaml -i --no-hw-flow-stat -c 4
Starting  TRex v2.85 please wait  ...
 You might need to run ./trex-cfg  once
EAL: Error creating '/var/run/dpdk': Read-only file system
EAL: Cannot create runtime directory
EAL: FATAL: Invalid 'command line' arguments.
EAL: Invalid 'command line' arguments.
EAL: Error - exiting with code: 1

So I'll add a volume also in that folder.

Testing is finished, now the data plane pods are passing this test related to readOnlyRootFilesystem feature, while testpmd is behaving correctly and the result in terms of performance is the same.
I've created this change in dallas-pipelines to reflect this update: https://github.com/dci-labs/dallas-pipelines/pull/1259


Error: Unsupported feature: LIMIT with non-integer literal

Getting the following error:
Error 1105: unknown error: unsupported feature: LIMIT with non-integer literal

Even though the query I'm running actually does use an integer, it's just interpolated.
Minimal repo:
_, err := db.Query(`SELECT * FROM foo LIMIT ?`, 10)
// err is "Error 1105: unknown error: unsupported feature: LIMIT with non-integer literal"

(maybe the error means non-literal integers are not supported? using LIMIT 10 instead of interpolating works.)

Thanks for the report, this is definitely a bug
I have a fix, should get it released in the next few days

awesome, thank you!


Feature request: Show function parameters inline for every function call

The feature would show Inline parameters
those parameters would be read-only annotations displaying inline in the editor - on every function call - like some extensions already have, but this would be for all programming languages.

Duplicate of #152597


Fixes #16

This adds the default options to the options variable, so no error is raised later

Thanks for the contribution!


fix: use revm patch

Blocked by https://github.com/bluealloy/revm/pull/182
Motivation
this should fix the recent debugger issues
https://github.com/bluealloy/revm/commit/136555437e1c410508aafdd9948a43477c0d64ee
ref https://github.com/foundry-rs/foundry/issues/2870

Solution
patch until new revm released

The updates are mostly internal. Externally it's mostly about renaming subroutine to journaled_state, replacing the Account::Filth flag with the corresponding boolean getters, and replacing the execution results from a tuple into a struct. ref #2878

New revm additionaly fixes this: https://github.com/foundry-rs/foundry/issues/2654


windows-compatible

Signed-off-by: Michael Riley<EMAIL_ADDRESS>

just realized getpwuid doesn't do what I thought it did. hold on.

Cool thank you, it works for me on windows with this


Cannot update the firmware on  luci-theme-openwrt-2020 .

After selecting the firmware, the upload button cannot be clicked.

Please try  https://github.com/openwrt/luci/pull/7200


[ISSUE CARBONDATA-84]Locking framework change

get dictionary lock location from CarbonTablePath
2.Change lock framework to accept locklocation

@gvramana please review it.

LGTM


Swap with parent/child assist should work on single-child Flex

Use case
If you have a code like this:
Scaffold(
  body: Column(
    children: [
      Padding(
        padding: const EdgeInsets.all(8),
        child: Text('Hello'),
      ),
    ],
  ),
);

You already can remove the Column.
Proposal
I'd like for the Swap with parent/child to work on single-child Flex so that, in cases like the above, I can place the Padding around the whole Column.

@FMorschel Looks similar to https://github.com/dart-lang/sdk/issues/31806 that you can check. If your case is different than it, then you will most probably need to raise in dedicated repo as above.

I thought that assists for Flutter were raised here. Sorry.
It is different. I'll create an issue there. Thanks!


Impossible to install Yii2 via composer

This morning I noticed that trying to install Yii2 via composer gets me this:
$ composer create-project --prefer-dist yiisoft/yii2-app-basic basic
Installing yiisoft/yii2-app-basic (2.0.4)
  - Installing yiisoft/yii2-app-basic (2.0.4)
    Downloading: 100%

Created project in basic
Loading composer repositories with package information
Installing dependencies (including require-dev)

  [UnexpectedValueException]
  Could not parse version constraint <=2.x: Invalid version string "2.x"

This was working fine a few days ago (last time I tried), so I'm guessing something in either Yii or one of the repos that Yii uses changed and the FXP plugin isn't able to parse the changes.

composer global update

for detail https://github.com/francoispluchino/composer-asset-plugin/pull/137

Duplicates #9231

@lynicidn @klimov-paul I read the entire discussion, but it's not very clear how exactly to fix this. I tried cleaning the cache, self-update, deleting global and project lock files and I still get the error.
Can you tell me what exactly I must do to fix this?

remove vendor also

I had to place "fxp/composer-asset-plugin": "dev-master" in my global composer.json.

Btw, I iterate what I said in https://github.com/yiisoft/yii2/issues/8688
FXP is completely and utterly rubbish.  Yii2 would be so much better ditching it.

@alexandernst there's such plan for 2.1.


Fix unit tests failed on JDK8

What is the purpose of the change
Fix https://github.com/apache/dubbo/actions/runs/6719173029/job/18260558947
Brief changelog
Verifying this change

Checklist

[x] Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Add some description to dubbo-website project if you are requesting to add a feature.
[ ] GitHub Actions works fine on your own branch.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 69.42%. Comparing base (aa631cd) to head (8b4a86c).
Report is 507 commits behind head on 3.2.

Additional details and impacted files
@@             Coverage Diff              @@
##                3.2   #13296      +/-   ##
============================================
- Coverage     69.48%   69.42%   -0.07%
  Complexity        2        2
============================================
  Files          1652     1652
  Lines         68955    68956       +1
  Branches      10053    10056       +3
============================================
- Hits          47916    47874      -42
- Misses        16402    16425      +23
- Partials       4637     4657      +20

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Add .gitattributes with export-ignore

Please add .gitattributes file for installing this library via composer with --prefer-dist option. Folder "tests" should be with export-ignore.

Thank you for the advice!


Flexible difficulty bug

I recently left the issue of a mythical 5ppl difficulty. Then I found another bug with the flexible difficulty of the raid.
The standard frame displays, for example 21H - when 21 people in a raid, and nMinimap shows averages indicators - is it possible to correct?

PS: Sorry for my English =\

Does this fix it? I'm not sure if it updates appropriately when people leave/join the raid though.
https://github.com/renstrom/NeavUI/commit/798d2bd6cf6b5f1163b00d1fc5767aa6f6607db9

I'm testing now.

It works, ty!

Great! Did you check if the number was updated when people left and joined?

Only left.

That's enough I guess :) Closing this now.


A new extension of SkipException to support retry check when exception happened

TestNG Version
Latest 7.0.0 SNAPSHOT
Expected behavior
Add a new extension of SkipException, to let it support to retry when skip exception happened, when met following conditions:

There is a field to control retry check turned on/off when skip exception happened.
Retry with skip only support at test method, not configuration method.
Implementation of IRetryAnalyzer is added for this test method.

Test case sample
will come up with a pull request.

@eyehwan - I am not quite sure I understand what exactly are we trying to solve using this PR #2108 Can you please help elaborate a bit more ?

Yes, of course.
Current retry machanism support to trigger retry only when assertion failed or runtime exception happened.
But there are some scenarios, when skip exception happened, it is also meaningful to trigger the retry.
That's why I provide a new type of skip exception here, when such skip exception happened, depending on whether we have IRetryAnalyzer implementations, we would decide if retry is needed.

A SkipException is specifically designed for skipping a test. Why would someone throw that when they want the test to be retried ? I am not sure I quite understand the use case.

Because the user who was writting test and the user who is using/running test may be different, they have different purpose to design and run the test, also on the skipException whether need to trigger retry.
Such case usually happened at some integration test of "complicated" products, for the same test, in the different level of integrations, skip is given different meanings.
I want to make skip exception to be flexible to suit such requirement.

Because the user who was writting test and the user who is using/running test may be different, they have different purpose to design and run the test, also on the skipException whether need to trigger retry.

What does this mean? Can you please elaborate ? From what i understand, you seem to be trying to Fix a design problem in your test framework, by putting a changeset in TestNG.

Such case usually happened at some integration test of "complicated" products, for the same test, in the different level of integrations, skip is given different meanings.

Why should exceptions have different meanings? Exceptions were never meant to be contextual. They were always meant to represent the exact same problem no?

Moreover, the changes look like they could very well reside within a test project and don't necessarily need to be part of TestNG right ?

Exceptions were never meant to be contextual.

I disagree with this point of view. The purpose of exceptions would be changed in different contexts.
The purpose of this pull request just want skip exception to be negotiable with outside.
Moreover, I also believe that is why "isSkip" exists as when SkipException created.

I disagree with this point of view. The purpose of exceptions would be changed in different contexts.

Do you want to cite out examples of this claim? I would be curious to know.

The purpose of this pull request just want skip exception to be negotiable with outside.

That should still be possible from outside via a TestNG listener no? Why would you want this to reside inside TestNG. This is what I am trying to understand.

Moreover, I also believe that is why "isSkip" exists as when SkipException created.

I wouldn't know the history context. @juherr What are your thoughts on this PR ?

Do you want to cite out examples of this claim? I would be curious to know.
That should still be possible from outside via a TestNG listener no? Why would you want this to reside inside TestNG. This is what I am trying to understand.

@krmahadevan, yes, of course I can put it outside TestNG, actually I already do so and be using it for a while.
The reason I recommend adding it inside TestNG is about benifits would be brought into TestNG:
Retry machanizm in TestNG could be enhanced by adding skip case. Current retry in TestNG only support failed status.
Thinking about this case:
After a test was designed and created, it is being used in the different levels of integration test. A "SkipExcpetion" as part of logic in the test usually means one condition can not be met to execute the rest of test.
For example one device is not stable occasionally, but the role of this device in the test could be changed in different test purposes or integration levels. It could be a key node or only an assitant node for the same test.
When it is just "an assitant node", If we can trigger retry machanism by adding extra recovery actions, device become stable, the test would be executed.
Otherwise the whole test session together with other tests should be re-executed, This is very time consuming for a large integration system, especially for a unstable device which is just an assitant tool, not the key part of test logic.

I Do agree with @krmahadevan A SkipException is specifically designed for skipping a test. Why would someone throw that when they want the test to be retried. Instead of throwing skip exception you should throw other meaningful custom exception.
Regarding the case you are considering, your framework/implementation can take care it by throwing meaningful custom exception that you can consider in retry analyzer or implementing appropriate listener. For example you can handle driver creation exception and throw custom exception. Another example is QAF provides driver listener and element listener where you can do the needful.

@eyehwan

The reason I recommend adding it inside TestNG is about benifits would be brought into TestNG:
Retry machanizm in TestNG could be enhanced by adding skip case. Current retry in TestNG only support failed status.

Sounds like a very good use case to live as a separate project. I think you should publish this as a separate library outside of TestNG because going by what you are saying its something like a decorator that enriches the current functionality. We would like to keep TestNG to enable such things and not necessarily absorb all possible customizations tweaks etc., that can be done to TestNG. Doing that would cause TestNG to bloat and we end up providing things that aren't necessarily needed by everyone.

We would like to keep TestNG to enable such things and not necessarily absorb all possible customizations tweaks etc., that can be done to TestNG. Doing that would cause TestNG to bloat and we end up providing things that aren't necessarily needed by everyone.

Okay, I understand. But considerring TestNG is not limited at unit test, but also declare to support many other types of test, I am hoping to get them more involved into TestNG. Let's discuss it next time.

Another example is QAF provides driver listener and element listener where you can do the needful.

@cjayswal , it looks like an good example of @krmahadevan mentioned above about "seperate library". Thanks, I will take a look at it,

Close: should be in a 3rd party lib


Feedback from user study: The value of sample isn’t apparent

Participants were not sure,
•	Why they would use the sample before trying on their own projects.
•	Why they needed to integrate to Azure pipelines
o	incremental build time
o	Additional overhead in installing Azure DevOps extension
•	Value of including automated checks compared to static analysis tools like ESLinkt and TSLint
Recommendation:
•	Explain the benefits of the sample in the high-level overview
•	Explain why an option to integrate with Azure pipelines can be beneficial, especially for visualizing failure details. How about including this as an optional step?

Add benefits of integrating automated accessibility checks in engineering pipeline in readme right after the description:

Automate accessibility checks in Continuous Integration and Pull Request builds
Visualize details of accessibility failures in build results page in Azure DevOps
Fail a build based on automated accessibility test results

Update text in the previous comment to,

Automated accessibility tests run during Continuous Integration and Pull Request builds, ensuring that all code changes are free of common easily-detected accessibility issues before they go to production.
Builds can be configured to fail based on the results of the automated accessibility tests, preventing both new accessibility bugs and regressions.
Failure details and ‘how to fix’ information can be viewed in Azure DevOps under Builds, making it quick and easy to investigate and resolve the accessibility issues.

Add the following to the beginning of readme to introduce the samples, explain the benefits and to specify applicability to web projects that have UI automation tests:
Watch a short intro video to get started with automated accessibility tests in Azure pipelines. Please note that these samples are applicable to web projects that have UI automation tests. Benefits include,

Automated accessibility tests run during Continuous Integration and Pull Request builds, ensuring that all code changes are free of common easily-detected accessibility issues before they go to production
Builds can be configured to fail based on the results of the automated accessibility tests, preventing both new accessibility bugs and regressions
Failure details and ‘how to fix’ information can be viewed in Azure DevOps under Builds, making it quick and easy to investigate and resolve the accessibility issues


Accelerated

Accelerated is crashing DF on butchering historical figures. Meph had some thoughts on what was causing the problem.

Edit4: About the "Do not use Accelerated! It's bugged, I'm working on it." message: Restore the bone tissues to normal, and there are no crashes anymore.


Add userData pointer to reallocateFn

In the spirit of this PR, I am trying to write a wrapper for Wren in Zig. Zig is very explicit about everything, including allocators.
Wren is currently written with a global malloc in mind. With this (sadly, breaking) change, reallocateFn accepts a void* userData. This can be used to locate an allocator instance, so that each VM can use its own allocation method (e. g. fast ones with limited memory for smaller VMs and general-purpose ones for larger VMs).
I only added void* userData and not WrenVM* vm since I thought that messing with the VM itself during allocations might not be too wise.
Breaking API changes
Added additional userData parameter to WrenReallocateFn.
typedef void* (*WrenReallocateFn)(void* memory, size_t newSize, void* userData);

I would always put user data in front, since it is some kind of anonymous
of object style call.

I was wondering if I should do that. I put it in the back to differentiate it from the usual WrenVM*, and because I thought that memory allocation functions feel different than the other ones. But I can change it and put the pointer in front.

It's fine on the right too, don't change it just yet.

Personally I think it's better on the right. It's similar to functions like pthread_create and others. Plus, it makes more sense for an allocator to not have that extra user data in front. This way you're just gonna use it like realloc(), with an extra NULL at the end most of the time

The fact that you want to differentiate it, is exactly an anti pattern that
C love, in the sense of using and abusing pointer cast.
About realloc, the argument is also a falcy if you look how realm API looks
like. And in the general case, the important thing is that all/most other
arguments are aligned so that they can be copied fast in worse case. But
anyway we are in a slow path, if we loose few cycle rearranging the stack
it is always minor to the heap management.

Is there anything I can change or do to get this accepted or rejected with a reason? I just published the initial code for the mentioned wrapper, and would love to be able to build it with the official source.

Wait, seems maintainer is busy. Bus factor is in effect.

Thanks @koljakube! It's reasonable to need access to the userData (that's why it exists).


Webapp doesn't expire "Connect to mobile" connection

Description
WalletConnect connections ("Connect to Web" on Mobile) are not removed after more than 24h of inactivity
Environment

Browser: Chrome
Wallet: Gnosis Safe Mobile
Chain: Rinkeby

Steps to reproduce

On the iOS mobile app: Settings -> Connect to Web -> Scan Code
Scan "Connect to Mobile" on the web app
Wait 24 hours (or adjust the expiry date on mobile) and make sure the mobile app is not able to tell the web app to drop the connection (use flight mode)
Make sure connection is not available on mobile anymore
Open web app

Expected result
Expected behavior: The connection should not be available anymore on web. At least it should be terminated, when it cannot be used
Obtained result
Observed behavior: The webapp tells me to sign the tx, but the mobile phone never gets the message (because the connection has been dropped on mobile.
This can happen weeks after the connection was established. When at least after 24h it should be expired.
Screenshots

@biafra23 is it a general WalletConnect thing or our setting? Never heard about the 24h expiry.

@biafra23, can you share the expiry timestamp found in your localStorage under the SAFE__lastUserProvider.expiry key? We do set an expiry of 24h but maybe we need also remove the WC cache.


Check integration test results

This PR adds a check to the multi-language-repo_test-autodetect-languages test that the expected number of databases were created. Currently we don't check anything except that it didn't crash. We could go even further and check
Here's an example of it failing: https://github.com/github/codeql-action/runs/685732844?check_suite_focus=true
Also only runs that test on one OS as I don't think running it on windows too is testing anything useful. We have other tests that run on all supported OSes. This should make the integration tests a tiny bit faster.
Merge / deployment checklist

Run test builds as necessary. Can be on this repository or elsewhere as needed in order to test the change - please include links to tests in other repos!

[x] CodeQL using init/analyze actions
[x] 3rd party tool using upload action

[x] Confirm this change is backwards compatible with existing workflows.
[x] Confirm the readme has been updated if necessary.

@Daverlo, do you have time to review this?


update to 2.8.1

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Distinguish error cases when operation is already finished

We need to distinguished states when operation is already canceled, expired or already authorized and provide special error codes for the Mobile Token application.
Issue #145 is related to this change.

Two cases can be distinguished:

OPERATION_ALREADY_FINISHED
OPERATION_ALREADY_FAILED

Operations can be canceled multiple times, because they are cancelable both via Web UI and Mobile Token app. So this case is not handled.


Remove duplicate dependency on jboss-invocation causing build warnings.

Introduced over the weekend via https://github.com/wildfly/wildfly/pull/15913 (FYI @yersan)

/retest

@yersan Good point, agreed, and done. Although – the ejb3/pom.xml dependencies are very out of order.

Ok, my interpretation of the order issue is that org.jboss.invocation:jboss-invocation-jakarta is brought in as transitive dependency by org.wildfly.core:wildfly-server, so it will place common classes before in the classpath, making the compilation to fail when used in conjunction with https://github.com/wildfly/wildfly-core/pull/5171
Both solutions should work, either exclude org.jboss.invocation:jboss-invocation-jakarta from org.wildfly.core:wildfly-server or place org.jboss.invocation:jboss-invocation at the beginning, as you did now.

Thanks @rhusar


Proposal: Switch stateChangeListener to accept multiple listeners

Been thinking there might be some use cases where one would want to add multiple, such as coloring the status bar when it's expanded.

With the addition of the Fragment sheet, I think we need to support this now.


Add possibility  to delete docs from Elasticsearch.

We recently had the use case to write and delete documents from elasticsearch using benthos. Currently I dont see the option in benthos to be able to delete documents from elasticsearch. Do you think this would be a useful feature? I am thinking of contributing this feature to this open source project, but would like to ask before if  you have thoughts about it. Thank you.

Hey @jann, this would be great. We could add an elasticsearch cache type that would enable this.

Hi @Jeffail. Would it be possible to dynamically write or delete documents based on a value in the metadata? What are your thoughts about this? Or would you rather cover this use case by running two benthos in parallel, one writing into elasticsearch the other deleting from it and filtering the corresponding delete/write messages before in a processor.

As an alternative, you're able to have http processor to perform a crafted REST API request to your target Elasticsearch.
https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-delete.html

Shouldn't be much of a problem given http processor supports interpolation in it.

Would it be possible to dynamically write or delete documents based on a value in the metadata?

Yeah, if it's a cache type then we can do all kinds of weird and freaky things with it.


Don't use ES6 class for auto updater

Don't use an ES6 class for the AutoUpdater class on Windows due to #4066
This was a regression introduced in #4121
This pull request also adds some initial specs for the autoUpdater to prevent future regressions like this.
Here is a pic of it now working on Windows 10:

Fixes #4346

Since ES6+ is the way of the future, I don't see this as a future-friendly PR.
You can easily enumerate through Classes prototype methods, just not through regular for-loops or Object.keys().
Wouldn't it just be better to modify remote.js or whatever to properly enumerate through the class methods?
const props = Object.getOwnPropertyNames(Object.getPrototypeOf(classInstance));

for (let name of props) {
    let method = callbacks[name];
}

Wouldn't it just be better to modify remote.js or whatever to properly enumerate through the class methods?

Since this was a regression I was hoping to get out a quick release with this fix in it.
Then we can decide how to fix #4066 correctly, add more testing in that area, and then port this class back over, it is very small and should be quite simple to get back to ES6.

@zcbenz are you okay with the fix here or would you prefer more generally fixing the remote module problem with ES6 classes?

/cc @jlord :eyes:


Add MessageBoxTimeoutA and MessageBoxTimeoutW

Add the missing, undocumented functions MessageBoxTimeoutA and MessageBoxTimeoutW, present since XP.

I cannot find these in the Windows SDK headers. Is there any official source for these definitions?

They're undocumented, but they've been present and functional since XP, and used since then.  In fact the standard MessageBox functions actually call MessageBoxTimeOutA / MessageBoxTimeoutW under the hood and pass a timeout of 0xFFFFFFFF.

Regardless, the policy of winapi is to only include bindings that have official headers from Microsoft.

These are useful functions though, used in the wild, which MS uses in its own implementations.  How about marking them with a warning?


chore: release 1.2.3

:robot: I have created a release *beep* *boop*
1.2.3 (2019-09-11)
Bug Fixes

deps: update dependency dns-zonefile to v0.2.3 (#296) (06b3f04)

This PR was generated with Release Please.

The release build has started, the log can be viewed here. :sunflower:

:egg: You hatched a release! The release build finished successfully! :purple_heart:


Refactor Selection widgets

Same type of refactoring using the new traitlets API to simplify the selection and multi-selection widgets.
One change here is that the selection_label attribute was removed and it is directly value that is synced with the front-end, but with a custom serializer that actually sends the label through the wire.
It allows to remove a complicated logic of locks that was put in place to cross-update label and value.
Besides, like for the range widgets, this fixes the potential inconsistent state issues that was due to validating things on change of attributes rather than before.

Besides, like for the range widgets, this fixes the potential inconsistent state issues that was due to validating things on change of attributes rather than before.

Finally, this removes much more code than it adds, which is a really good thing.

Looks like the multi select Python test is broken

This is ready.

Not anymore.

This can be merged as-is. I have more simplification to come but I cannot do what I want because of a couple of bugs I found in traitlets regarding union traits which I will fix.
I will get back to this later.

I think later we'll want to revisit the subject of user API convenience regarding this Widget.


Add retry ability to RemoveDirFixed

Fixes https://github.com/dotnet/android/issues/9133
Context: https://learn.microsoft.com/visualstudio/msbuild/copy-task?view=vs-2022
The Design Time Build (DTB) seems to lock files and directories during its build process.
This is not by design it is just that sometimes a build will try to do something with a
file that the DTB already has open.
Users will sometimes see this error.
Error (active)	XARDF7019	System.UnauthorizedAccessException: Access to the path 'GoogleGson.dll' is denied.
   at System.IO.Directory.DeleteHelper(String fullPath, String userPath, Boolean recursive, Boolean throwOnTopLevelDirectoryNotFound, WIN32_FIND_DATA& data)
   at System.IO.Directory.Delete(String fullPath, String userPath, Boolean recursive, Boolean checkHost)
   at Xamarin.Android.Tasks.RemoveDirFixed.RunTask() in /Users/runner/work/1/s/xamarin-android/src/Xamarin.Android.Build.Tasks/Tasks/RemoveDirFixed.cs:line 54	MauiApp2 (net9.0-android)	C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.6.340\tools\Xamarin.Android.Common.targets	2503

PR https://github.com/dotnet/android-tools/pull/245 introduced the concept on a "Retry" in the cases of UnauthorizedAccessException or IOException when the code is ACCESS_DENIED or
ERROR_SHARING_VIOLATION.  This commit builds on that work to use the API's added to add retry semantics to the RemoveDirFixed task.
This also simplifys the Task somewhat as it had quite complete exception handling.

Fixes https://github.com/dotnet/android/issues/9133

Context: https://github.com/dotnet/android-tools/commit/60fae1924e2d71f31dc1ed05f7346fd7874d6636

Much to our chagrin, in .NET 6+ it is possible for Design-Time Builds
(DTBs) to run concurrently with "normal" builds, as there is nothing
within the [.NET Project System][0] or [Common Project System (CPS)][1]
which would actively *prevent* such concurrency.

Consequently, it is possible to encounter locked files and
directories during the build process, and user may see errors such as:

	Error (active)	XARDF7019	System.UnauthorizedAccessException: Access to the path 'GoogleGson.dll' is denied.
	   at System.IO.Directory.DeleteHelper(String fullPath, String userPath, Boolean recursive, Boolean throwOnTopLevelDirectoryNotFound, WIN32_FIND_DATA& data)
	   at System.IO.Directory.Delete(String fullPath, String userPath, Boolean recursive, Boolean checkHost)
	   at Xamarin.Android.Tasks.RemoveDirFixed.RunTask() in /Users/runner/work/1/s/xamarin-android/src/Xamarin.Android.Build.Tasks/Tasks/RemoveDirFixed.cs:line 54	MauiApp2 (net9.0-android)	C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.6.340\tools\Xamarin.Android.Common.targets	2503

dotnet/android-tools@60fae192 introduced the concept of a "Retry" in
the cases of `UnauthorizedAccessException`s or `IOException`s when
the code is `ACCESS_DENIED` or `ERROR_SHARING_VIOLATION`.

Builds upon that work to use the API's added to add retry semantics
to the `<RemoveDirFixed/>` task.

This also simplifies the Task somewhat as it had quite complex
exception handling.

[0]: https://github.com/dotnet/project-system
[1]: https://github.com/microsoft/VSProjectSystem


Turn serializer enums into enum classes.

Change the serializer enums into enum classes (thanks to @pphaneuf  for slicing this out of my monster serialization PR!)

You're right, it's not showing.

Pushed it to Reitveld to see if that'll do a better job: http://codereview.appspot.com/271700043

Reviewed on Rietveld. Looks good.


Inserting an InsightsMiddleware before widgets results in urlSynced-state being cleared on reload

🐛 Bug description
When we createInsightsMiddleware and insert that component before other widgets in an <InstantSearch> page, any state that is in urlSync gets erased on page load (such as pressing Enter or navigating from another page).
CC @Haroenv with whom I discovered the root cause of the UI issue.
🔍 Bug reproduction

Create an insights middleware that sets some stuff
Insert it in your <InstantSearch routing={true}> page before other widgets (such as <RefinementList>)
Click a filter to set some urlSync-ed parameters in the URL
Click on your URL and press enter
See the page reloading: the url is first kept, then erased during a second painting of the page

:curly_loop: Workaround
We realized that changing the position of the middleware in the DOM, from:
<InstantSearch>
  <InsightsMiddleware />
  <RefinementList />
  <Hits />
</InstantSearch>

to
<InstantSearch>
  <RefinementList />
  <Hits />
  <InsightsMiddleware />
</InstantSearch>

is enough to workaround the race condition between the middleware and the other widgets. :thinking:
Live reproduction:
https://codesandbox.io/s/nameless-forest-chr25g?file=/App.tsx
💭 Expected behavior
I'd expect the middleware to not clear the other widgets' state, regardless of where it is inserted.

A smaller reproduction is:

describe('integration', () => {
  test('does not write to the URL on load', async () => {
    const router = history({
      writeDelay: 0,
    });
    const routerWriteSpy = jest.spyOn(router, 'write');
    const search = instantsearch({
      indexName: 'instant_search',
      searchClient: createSearchClient({
        // @ts-expect-error these types are not part of "SearchClient", but a real client exposes it
        applicationID: 'abc',
        apiKey: 'def',
      }),
      routing: {
        router,
      },
    });

    search.start();

    search.use(
      createInsightsMiddleware({
        insightsClient(eventName, ...args) {
          if (eventName === 'onUserTokenChange') {
            const [cb] = args;
            cb('token');
          }
        },
      })
    );

    await wait(1);

    expect(routerWriteSpy).toHaveBeenCalledTimes(0);
  });
});

essentially what happens is there are two parts in the insights middleware which add widgets:
https://github.com/algolia/instantsearch.js/blob/55313e4ea4105b777f3f102e9f48a7e440496d25/src/middlewares/createInsightsMiddleware.ts#L109-L112
https://github.com/algolia/instantsearch.js/blob/55313e4ea4105b777f3f102e9f48a7e440496d25/src/middlewares/createInsightsMiddleware.ts#L115-L121
If this code happens after start (eg with React InstantSearch Hooks, where start happens immediately) the resulting addWidget triggers the change event on middleware, thus a write in the URL, even though nothing meaningfully has changed.
I think a way to solve this could be to add a static configure-like widget to InstantSearch root so global parameters can be set (should this be without searching, or is that no issue?) or maybe the main index helper can be used (although that seems counter to the regular idea of "every parameter is owned by a widget")

The reason the listed workaround works is because it triggers the search with userToken and clickAnalytics after the first widgets have mounted, and thus possibly also subsequently (unless the scheduling we have on searches prevents it), but it avoids writing a url before other widgets are mounted, and thus it would be empty.
Alternatively we could add an api to React InstantSearch to add middleware before start by making middleware a prop to the InstantSearch component, which could use the insights middleware as it is recommended for InstantSearch.js


added template creation

The name field doesn't show what I type in:

I get an error when I click on the edit button of a template:

I can't unselect the right side:


fix: move index to src instead of root

chore: clean up imports and configs
I have a preference of having my imports alphabetized by package name.
You're absolutely welcome to ask me to revert those changes, it's just
a preference of mine. I updated the build command to use the specific
tsconfig.build.json that will allow for the base tsconfig.json to
reference all ts files, while the build one only references the src
directory. Also switched out rm -rf for rimraf to take into account
those who may be on windows (and as the package was already installed).
All tests still pass, and the Node REPL pulls in the correct functions
when using require('./').
fix #9

Hi @jmcdo29 and @johnbiundo, I'm running into the same problem as #9, the dist folder wasn't included in the npm package. Can we got this PR merged and publish a new version?


binder: skip all tests on ios

They don't build due to -DNO_GRPC_BINDER.

LGTM. @eugeneo would you like to also take a look?
cc @rock1246


Reverse the Circular Doubly Linked Lists Recursively

Is your feature request related to a problem? Please describe.
The problem is to Reverse a Circular Doubly Linked Lists Recursively
Describe the solution you'd like
I would like to provide a C++ coded solution for this problem

@smv1999 I would like to work on this

Sure @kiruba-r11 , you can go ahead !


Update installed before deadline without notifications

Hello,
We are currently trying Super to check if it can work for us. This morning, it installed an update (14.3.1) by itself without even prompting me (We use Jamf API credentials). I was a bit taken aback for two reasons:

I was expecting at least a notification telling me the update was installing and my Mac would reboot after that. But I only got the built-in macOS notification telling me my Mac will reboot in 1 minute (Yep, I keep them at the moment but the will be muted in production)
The deadline for that update was on February the 14th so the update installed itself 2 days earlier than planned.

I can't explain why the update have been installed before reaching the deadline and without even being notified. It's the second time Super is installing an update without prompting me and before the deadline is reached so either there's an issue with my config or there's a bug somewhere and I think I will need your help to sort it out. :)
I have attached logs for this morning. If needed, I can also give the next set of logs.
super-logs-2024-02-12.08-10-30.zip

@Tuttu  - Does this time frame look right?
WorkflowZeroDateAutomatic = "2024-02-09:09:19";
DeadlineDaysSoft = 5;
2024-02-11 18:12:51.  14.3.1-23D60 update is discovered by Software update.
2024-02-11 19:18:57. You choose to defer by for one day.
2024-02-11 19:48:47  Super launches itself.  Mac OS installer preflight begins no prompt.

Hello @iancd-hofy ,
Yep, it looks right. The Mac was opened and running at this time and date. I was watching a replay and then left the Mac idle (Completely forgot it was there while doing some work at home 😅) so it was idle with the lid opened and with a replay that was ended still in full screen but the screen itself went to sleep.
I don't explain why it decided to install the update before the deadline though.

@Tuttu I've experienced something similar with a few Apple silicon devices where my soft deadline is ignored but did not have a verbose log like yours which was useful to examine.  I am not using Jamf.
I also can't explain why it decided to install the updates.
Do you have a Jamf or some sort of cron script script which manually launched super around the 2024-02-11 19:48:47 mark?

@iancd-hofy I don't think so. All we have is a Jamf policy to install Super which has 3 arguments (The Jamf client ID and secrets and the --reset-superargument) and which is executed only once.
In the logs, we can see that the super daemon started first at 18:12, when I have booted the Mac. It fails to authenticate with the Jamf Pro API and then perform a full update/upgrade check. super finds the 14.3.1 minor update available and at 18:13:05, the bootstrap token is successfully escrowed and validated with the Jamf Pro server.
Right after that, it says that it is Unable to validate the saved --auth-jamf-client credentials and the workflow fails. It will auto-launch again 60 minutes later.
Fast forward and it's now 19:13. super kicks again and shows the IBM notifier windows asking to chose between a deferral or a reboot. I'm not in front of the Mac so the windows times out and select the 30 minutes deferral automatically.
Fast forward again and it's now 19:48. super kicks once more and shows the IBM notifier windows asking to chose between a deferral or a reboot. Here again, I'm not in front of the Mac so the windows times out and select the 30 minutes deferral automatically.
It's not 20:28 and we are in for yet the same loop. See you again in 30 minutes.
You know the drill. It's 20:53, nobody's in front of the Mac. cya at 21:33.
New cycle at 21:38 and then, I notice the Mac and stop it before 30 more minutes have ellapsed.
We now are on Monday and it's 7:57 when I boot the Mac and start working. super goes to life and what's following is a mystery to you as the logs stops here so I will tell you the rest of the story.
It tries to download the update but fails after a timeout. It's 8:24 when that happens so super will start again at 9:24.
Fast forward, it's 9:24. And this is when it has happened. I'm adding all the other logs to that message so you can also review them. 😉
I also checked all my archives and unfortunately, I don't have the logs for the first time it happened on the 8th of February. ☹
super-logs-MDB.zip

@Tuttu  Thanks for the background notes. I will look over these new logs. For info, I've seen similar behaviour in my org on multiple devices when the soft deferral deadline is not respected, although I have not been able to replicate on my own device where I'm collecting verbose logs (like you).
We employ a regular weekly MDM command that starts super and checks for new versions, and reinstalls super if it's been deleted - that runs in addition to super's internal scheduling (which is now much improved in version 4 rewrite). It may even run in parallel if a super operation is running.  We've stopped that command for the period until can track this issue. It's not good experience for users in the middle of working to be pushed into OS update.
There has been some media reports of macOS automatically installing without prompting the user but to my knowledge this is a Ventura to Sonoma major upgrade, not a 14.2 > 14.3 or 14.3 > 14.3.1 like you have seen. Thanks for sharing.

Hello @iancd-hofy !
Is it normal that a minor update is installed while the computer is turned on and waiting on the login screen with no user connected at all? Or is it a bug?

Hello @iancd-hofy !
Is it normal that a minor update is installed while the computer is turned on and waiting on the login screen with no user connected at all? Or is it a bug?

Hello @Tuttu   Just following up here that with with 14.4.1 I was able to replicate the problem. However it was found to be an error on our part with engineering of the Super update script command that ran on a schedule for us.  Since disabling the bad script we've had no problems.
I hope you have not had repeats of the issue yourself.  Unless we more reports it would be a courtesy to the developer to close this issue I think because it's been open for a while now.

Hello @iancd-hofy ,
Just this morning, my Mac  has once again had a weird behavior. I still need to read the logs to know what really happened but I'm starting to feel like the issue comes from a weird configuration on my end. Looks like my Mac is the only one affected in our fleet.

Please try the latest release of super as it may resolve this issue: https://github.com/Macjutsu/super/releases/tag/v4.1.0-beta1

Hello,
I will give it a try next week as I plan to work on Super at that time. I will let you know if that solves that issue for me. :)

There have been so many changes to the latest version of super that I'm closing this issue.
https://github.com/Macjutsu/super/releases/tag/v5.0.0-beta3
If you find it persists with the latest builds of super please open a new issue.


Make ssh-agent private keys comptaible with WinSCP and similar software

I suggest with much humbleness to make private keys loaded to ssh-agent accessible to WinSCP (and other similar software) as it would release users from having to convert keys to ppk and storing extra files (Putty bundle and at least 2 keys for root and usual user in the same dir).
This would result in more minimal and comfortable desktops and will ease WinSCP developers in making it compatible with WSL as well.

Very cool suggestion but I think this functionality may create security nightmares if baked in.
It's technically already available if you are willing to do some heavy lifting-
We have  https://github.com/xilun/cbwin to run a windows program from WSL.
Modify your ssh-agent program to run use cbwin to launch pagent (putty-agent?) with the right credentials.

@Benosika, I would suggest updating your title to reflect the nature of your feature request!

I just wanted to let you know: the Win32-openssh project of the powershell team does integrate into the native Windows keyring for single sign-on. It was actually pretty annoying for them to rewrite the whole backend of openssh to support this integration with the Win32 crypto API.
This idea is a nonstarter for WSL. You'd be better off asking the PuTTY and WinSCP guys to support the openssh key format.

Nevermind the fact that the openssh key format is the standard format and ppk is not.


Merge layouts

Q
A

Is bugfix?
❌

New feature?
❌

Breaks BC?
✔

Fixed issues
#121

Thanks.

Thanks.


⚠ Processors has degraded performance

In cc328b0, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 42 ms

Resolved: Processors performance has improved in 08c8ec2.


fix #2309 - DST related issues in recurrence rules

Types of changes

Changes visible to users:

[ ] New feature (prefix: feat - non-breaking change which adds functionality)

Issue/discussion:
WARNING: If the link is absent, the PR may be closed without review, due to the workload that such reviews usually require.

[ ] Breaking change (prefix: feat!! or fix!! - fix or feature that would cause existing functionality to not work as expected)

Issue/discussion:

[x] Bug fix (prefix: fix - non-breaking change which fixes an issue)
[ ] Documentation (prefix: docs - improvements to any documentation content for users)
[ ] Sample vault (prefix: vault - improvements to the Tasks-Demo sample vault)
[ ] Contributing Guidelines (prefix: contrib - any improvements to documentation content for contributors - see Contributing to Tasks)

Internal changes:

[ ] Refactor (prefix: refactor - non-breaking change which only improves the design or structure of existing code, and making no changes to its external behaviour)
[ ] Tests (prefix: test - additions and improvements to unit tests and the smoke tests)
[ ] Infrastructure (prefix: chore - examples include GitHub Actions, issue templates)

Description

moment().local(true) incorrectly handles the early hours of the day on which DST is entered into. This PR is a workaround for that bug by doing the conversion at noon instead of midnight. Additionally it also replaces the incorrect use of window.moment with window.moment.utc when the intending to work with UTC time.
Motivation and Context

Fixes #2309
How has this been tested?

Tested the individual functions used with example inputs in a node interpreter.
Screenshots (if appropriate)
Checklist

[ ] My code follows the code style of this project and passes yarn run lint.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] My change has adequate Unit Test coverage.

Terms

[x] My contribution follows this project's contributing guide
[x] I agree to follow this project's Code of Conduct

Hi @ishanarora, thank you very much indeed for working on this.
The change

moment().local(true) incorrectly handles the early hours of the day on which DST is entered into. This PR is a workaround for that bug by doing the conversion at noon instead of midnight.

Will there still be a problem for Time Zones more than 12 hours from UTC?

Additionally it also replaces the incorrect use of window.moment with window.moment.utc when the intending to work with UTC time.

Manual testing
I appreciate the console output you put into #2309 gives you confidence in the fix on your machine. Thank you.
Proving and protecting the fix
However, we would definitely need to see failing tests - new tests that failed with the code before this change - before merging this. Both to confirm the understanding and ensure that the fix remains fixed.
The current tests
At the moment our automated tests are all run with this:
https://github.com/obsidian-tasks-group/obsidian-tasks/blob/b0b13209b9ad49e4924a9dcb281f05be751a5b17/tests/global-setup.js#L1-L3
Adding a failing test
With the following diffs, and running against the current Tasks code on main, I saw this new test fail:
Index: tests/Task/Recurrence.test.ts
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/tests/Task/Recurrence.test.ts b/tests/Task/Recurrence.test.ts
--- a/tests/Task/Recurrence.test.ts	(revision a64572226b8363d42a0520795ced3cf99d200ab1)
+++ b/tests/Task/Recurrence.test.ts	(date<PHONE_NUMBER>805)
@@ -131,6 +131,22 @@
         expect(next!.scheduledDate).toBeNull();
         expect(next!.dueDate).toEqualMoment(moment('2021-02-28'));
     });
+
+    it('reccurs correctly close to NZST daylight time switch', () => {
+        // Arrange
+        const recurrence = Recurrence.fromText({
+            recurrenceRuleText: 'every week on Sunday',
+            occurrence: new Occurrence({
+                dueDate: moment('2024-09-22').startOf('day'),
+            }),
+        });
+
+        // Act
+        const next = recurrence!.next();
+
+        // Assert
+        expect(next!.dueDate).toEqualMoment(moment('2024-09-29'));
+    });
 });

 // Test cases where a task has a non-existent due, scheduled or start date.
Index: tests/global-setup.js
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/tests/global-setup.js b/tests/global-setup.js
--- a/tests/global-setup.js	(revision a64572226b8363d42a0520795ced3cf99d200ab1)
+++ b/tests/global-setup.js	(date<PHONE_NUMBER>702)
@@ -1,3 +1,3 @@
 module.exports = async () => {
-    process.env.TZ = 'UTC';
+    process.env.TZ = 'Pacific/Auckland';
 };

The output was:

Problems with the failing test
Unfortunately a load of other date-related tests then fail with the change of time zone...
So somehow this code needs to be changed so that the time-zone is specified only inside that one test.
After that, I can generalise it to add tests for more time zone date boundaries, and more times of day.
What next?
I would appreciate some help researching how to correctly change time zones inside individual Jest test cases...

Will there still be a problem for Time Zones more than 12 hours from UTC?

No, the problem is unrelated to the hours from UTC. It has to do with the local time at which the DST kicks in (typically somewhere between midnight and very early morning). moment().local(true) does not correctly handle inputs on the first day of DST before DST actually kicks in. For example in NZ DST kicked in on 2024-09-29 at 2 am, and so moment().local(true) outputs incorrectly for any time before 2 am on 2024-09-29. By using moment().local(true) at noon time we avoid these early hours. I have
Following output demonstrates this for Chatham Standard Time Zone (UTC+12:45 +1 for DST):
root@accd8cbf3f5e:~# TZ=Pacific/Chatham node
Welcome to Node.js v22.9.0.
Type ".help" for more information.
> var moment = require('moment');
undefined
> moment.utc('2024-09-29T00').local(true)
Moment<2024-09-28T23:00:00+12:45>
> moment.utc('2024-09-29T01').local(true)
Moment<2024-09-29T00:00:00+12:45>
> moment.utc('2024-09-29T02').local(true)
Moment<2024-09-29T01:00:00+12:45>
> moment.utc('2024-09-29T03').local(true)
Moment<2024-09-29T02:00:00+12:45>
> moment.utc('2024-09-29T04').local(true)
Moment<2024-09-29T04:00:00+13:45>

The above failing test passes with only the .add(12, 'hours') change in this PR.
That means that more failing tests are needed to demonstrate the need/effect of each of the .utc additions...

The above failing test passes with only the .add(12, 'hours') change in this PR.
That means that more failing tests are needed to demonstrate the need/effect of each of the .utc additions...

Hi again @ishanarora, it would really help if you could find/share any examples where the recurrence results are wrong without each of the two .utc additions - then I can write some tests for them.
Thanks in advance.

Hi @claremacrae. Following is an example of the problem with not using the two .utc additions:
Consider process.env.TZ = 'Pacific/Midway', after = moment('2024-08-01') and RRule text 'every month'
Now as a result of the following lines https://github.com/obsidian-tasks-group/obsidian-tasks/blob/b0b13209b9ad49e4924a9dcb281f05be751a5b17/src/Task/Recurrence.ts#L153-L154 after = Moment<2024-08-01T00:00:00Z> (a UTC midnight timestamp with UTC timezone) and next = Moment<2024-08-31T13:00:00-11:00> (another UTC midnight timestamp but with local timezone). This results  diffMonths = 0 in the lines https://github.com/obsidian-tasks-group/obsidian-tasks/blob/b0b13209b9ad49e4924a9dcb281f05be751a5b17/src/Task/Recurrence.ts#L207-L211
Conversely if we tested this in a hypothetical UTC+24 timezone then diffMonths would be 2.
Adding the .utc makes next = Moment<2024-09-01T00:00:00Z> which gives the correct diffMonths.
Moreover the .utc additions bring the code in line with the following code comments:
https://github.com/obsidian-tasks-group/obsidian-tasks/blob/b0b13209b9ad49e4924a9dcb281f05be751a5b17/src/Task/Recurrence.ts#L150-L152
Nevertheless this bug doesn't propagate further because we don't check for equality in the line https://github.com/obsidian-tasks-group/obsidian-tasks/blob/b0b13209b9ad49e4924a9dcb281f05be751a5b17/src/Task/Recurrence.ts#L213 and also because there are no known UTC+24+ timezones.
Having said all that, I am happy to remove the .utc additions from this PR since they don't appear to affect https://github.com/obsidian-tasks-group/obsidian-tasks/issues/2309 . What do you think?

Wow, thank you for a very clear explanation.
Let's keep the 2 etc changes because of the following:

Moreover the .utc additions bring the code in line with the following code comments:
https://github.com/obsidian-tasks-group/obsidian-tasks/blob/b0b13209b9ad49e4924a9dcb281f05be751a5b17/src/Task/Recurrence.ts#L150-L152

I've given up writing an automated test for this, after many hours.
I've settled on a manual test, and some associated documentation for contributors, in:

https://github.com/obsidian-tasks-group/obsidian-tasks/pull/3144


Enable and fix Catch test

Enabling unit test would help capture bugs like #5, and also allow better validation of new functionalities like https://github.com/sympiler/sympiler/issues/7 . This PR is just to enable the existing test sptrsv_tests.cpp; will add more tests in later PRs.
Currently the Catch test target is commented out:
https://github.com/sympiler/aggregation/blob/da104fa343672469f2000efa4285dccb32107370/CMakeLists.txt#L151-L153
Uncommenting the lines leads to compile errors with gcc-11.3:
[ 98%] Building CXX object Catch_tests/CMakeFiles/Catch_tests.dir/sptrsv_tests.cpp.o
In file included from /usr/include/signal.h:328,
                 from /work/Catch_tests/catch.hpp:7712,
                 from /work/Catch_tests/sptrsv_tests.cpp:7:
/work/Catch_tests/catch.hpp:10453:58: error: call to non-'constexpr' function 'long int sysconf(int)'
10453 |     static constexpr std::size_t sigStackSize = 32768 >= MINSIGSTKSZ ? 32768 : MINSIGSTKSZ;
      |                                                          ^~~~~~~~~~~
In file included from /usr/include/x86_64-linux-gnu/bits/sigstksz.h:24,
                 from /usr/include/signal.h:328,
                 from /work/Catch_tests/catch.hpp:7712,
                 from /work/Catch_tests/sptrsv_tests.cpp:7:
/usr/include/unistd.h:640:17: note: 'long int sysconf(int)' declared here
  640 | extern long int sysconf (int __name) __THROW;
      |                 ^~~~~~~
In file included from /work/Catch_tests/sptrsv_tests.cpp:7:
/work/Catch_tests/catch.hpp:10512:45: error: size of array 'altStackMem' is not an integral constant-expression
10512 |     char FatalConditionHandler::altStackMem[sigStackSize] = {};
      |                                             ^~~~~~~~~~~~
gmake[2]: *** [Catch_tests/CMakeFiles/Catch_tests.dir/build.make:104: Catch_tests/CMakeFiles/Catch_tests.dir/sptrsv_tests.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:334: Catch_tests/CMakeFiles/Catch_tests.dir/all] Error 2
gmake: *** [Makefile:91: all] Error 2

Updating to the latest Catch v2.13.10 solves the bug. Still using the single-header v2 branch of Catch, not yet changing to the multi-header v3 branch.
Also changed the include files from Sparse_BLAS_INC to Sparse_TRSV_INC, and Sparse_BLAS_SRC_FILES to Sparse_TRSV_SRC_FILES, since the former is not defined elsewhere even in the parent Sympiler repo.

The unit tests should also run within github workflows for automatic CI. Currently only the demo examples  get run, which is not sufficient for validating advanced features.

Thank you, adding test to the flow was on my long list.