Why is this showing 4 executions?

Shouldn't each job have its own execution?

❯ bacalhau job run job.yaml
Job successfully submitted. Job ID: j-1991a558-eb9f-4b59-b520-9021e5dcc8bb
Checking job status... (Enter Ctrl+C to exit at any time, your job will continue running):

	Communicating with the network  ................  done ✅  0.0s
	   Creating job for submission  ................  done ✅  1.1s
	               Job in progress  ................  done ✅  0.5s

To get more details about the run, execute:
	bacalhau job describe j-1991a558-eb9f-4b59-b520-9021e5dcc8bb

To get more details about the run executions, execute:
	bacalhau job executions j-1991a558-eb9f-4b59-b520-9021e5dcc8bb

❯ bacalhau job describe j-1991a558-eb9f-4b59-b520-9021e5dcc8bb
ID            = j-1991a558-eb9f-4b59-b520-9021e5dcc8bb
Name          = Edit Justicons
Namespace     = default
Type          = batch
State         = Completed
Count         = 1
Created Time  = 2024-03-28 19:01:46
Modified Time = 2024-03-28 19:01:47
Version       = 0

Summary
Completed = 1
Failed    = 3

Executions
 ID          NODE ID     STATE      DESIRED  REV.  CREATED  MODIFIED  COMMENT
 e-3fd89c1d  n-9ae55f76  Failed     Stopped  3     6s ago   6s ago    error calculating resource requirements
                                                                      for job: error getting job disk space re
                                                                      quirements: volume not in allowed paths
 e-95cf5a94  n-002fd8e4  Failed     Stopped  3     6s ago   6s ago    error calculating resource requirements
                                                                      for job: error getting job disk space re
                                                                      quirements: volume not in allowed paths
 e-ba6ff1b5  n-cbc0e2d9  Completed  Stopped  6     6s ago   5s ago
 e-fce4c2ab  n-5655e4a2  Failed     Stopped  3     6s ago   6s ago    error calculating resource requirements
                                                                      for job: error getting job disk space re
                                                                      quirements: volume not in allowed paths

Standard Output
Color file /justiconsapp/color.txt updated to black.

volume not in allowed paths

It might be best for the job not to be scheduled on nodes that don't have the volume, surely bidding should have picked this up?

Exposed volumes aren't included in node metadata afaik so there's no orchestration-time filtering of inputs.


Deploy new hmt token AND escrow contracts

Deploy again the hmtoken+escrow contracts, since they have been recently changed in order to save gas.
Possibly wait for testing the whole integrated hCaptcha suit before deploying.

@uivlis will try to close this out today / tomorrow

New HMToken: 0x4C18A2E51edC5043e9c4B6b0757990A4Ac13797f


2008R2 Windows Updates hangs

I've spent the better part of the day trying to troubleshoot this one to no avail.
From a clean clone, enabling gui, and building the windows_2008_r2.json when the answer file reaches win-updates.ps1 , it gets stuck at the first call to $script:UpdateSearcher.Search .
In addition if you skip that and attempt to use the GUI to run windows updates, it will install the latest windows update agent, but then get stuck on Checking for Updates.
Can anyone else confirm this issue? I believe this is a Windows Update bug, but I've tried every hack and slash trick to repair it on google to no avail.

After leaving this running over night it does actually complete, but based on the timing it looks like it adds about 4 hours to the completion. I know it spends at least the first hour doing seemingly nothing.
I'll close this issue in a few days if no one has any feedback.

@markhuber There is such a massive amount of updates for Windows 2008 R2, it's possible the first hour is spend just downloading stuff.

You might consider tweaking MaxUpdatesPerCycle further. Check out this issue: https://github.com/joefitzgerald/packer-windows/pull/135

Windows 2008R2 updates often take 4-6 hours to complete. Consider upgrading to Windows 2012R2, it only takes 1 to 2 hours :wink:
This is why I used to chain all my Packer builds using the ISO build -> VMX builder where the ISO builder just applies Windows updates and subsequent builds specialize the box into a web server etc.


Logging revamp.

Currently if you're an active server the CLI is a nightmare to work with.
I would propose a revamp of the logging system to address a few things:
Logging to a file:
This would just be nice to contain ALL errors and debug data in a way we can easily download and parse elseware.
This file should be cycled daily/hourly to prevent it eating a ton of space.
Limiting what's piped to dashboard/cli:
On an active server {getting thousands of requests a second} the CLI is impossible to sanely use.
So my suggestion is to add labels to printed things, and filter out only requested things in the cli.
Potentially either turn it into a separate tab that filters things out client side, or adding a command to toggle specifc filters.
Basically I want to be able to use the cli on an active server without seeing requests/errors

Yeah, I've also noticed this issue in my repository and it's definitely something that must be improved. In general, I think it could be implemented with #444.

Ok, I've made a tiny library based on a code from my another project:

https://github.com/dzikoysk/dynamic-logger

We can now perform various operations and we're not limited to tinylog possibilities. We can also get rid of custom writer and simplify tests that relay on this mechanism.
I wonder if we want to only dynamically switch between logging levels, e.g.:
$ level DEBUG
// cli now prints everything
$ level INFO
// reduced log

Or do we really want to provide some kind of advanced querying 🤔 I'd limit runtime querying possibilities to reduce the overhead caused by log storage.

I would say if you want to expand runtime logging in the CLI window, then only make it for new messages. Admins should be able to access the logs folder and get any previous messages.
The other option is to make the CLI ONLY commands/responses no way to change the logger level. But add a new log tab that shows everything, but allows for toggling different levels on/off with a checkbox. Something like the Minecraft Launcher's logger: (ignore the horrible colors)

Available UI filters in 3.x:
https://user-images.githubusercontent.com/4235722/131699993-f02251a5-0394-42b9-8b45-16595fd5124b.mp4


Improve comment in Fluentd to ES logging config file

@a-robinson you make an excellent point that this config file should be better documented.

LGTM


Upgrade the test suite mocks

NOTE
This issue is here because the work has already been done for my own project here, but enough changes have been made to the point where I think it may be useful for pydis to reap the benefits as well.
Description
Initially, I took the mocks for my own project, and added a few mocks that I needed, but while working through them, I noticed some shortcomings. Those shortcomings are addressed in the file change I made.
A short list of changes are as follows:

add discord.Thread mock
make mocks NonCallable mocks since you cannot call a message (or any) instance
ensure mock returns return the correct type, eg channel.send() will return a MockMessage

The most important part of the changes is the final change. This uses the typing information provided by discord.py in order to mock all functions that are mockable to return the correct mock type when they are called. This means that message.create_thread() will return a MockThread, or channel.send() will return a MockMessage. This is all done by utilising the typing system, and the fact that the public api of dpy 2 is typed.

I stumbled across this as I was looking for test suites. Just an idea... Would it make sense to extract those Mocks into a lib?

Yeah a discord.py mock library is a nice idea, but it's not something we're likely to pursue at the moment. Our approach to the mocks (and tests in general) is "good enough", but maintaining a high-quality library would require significantly more work, especially if we try to cover all of discord.py instead of just the parts we need.

Yes, true. That would require a lot more of work.
Covering everything would be nice, yes.. but starting off small and, if someone needs a mock, adding it step by step would also work.
I myself just started to dig into testing, so I can't really help in that way :/

I think it's fine to only extend our mocks as needed.


Add Auth example #1

In this case，I did not find auth services in this armeria-example，so it take me a little time to understand the armeria
framework 。On the other hand,Without this example, I am play more attentive to understand this framework. Helped me a lot, thanks！
What I did is
1.Add an example of an class MyAuthHandler.java implements Authorizer Interface.
2.Add an example of an services decorate with AuthServiceDecorator and LoggingServiceDecorator.

Hi @opencroco, thanks for adding a nice example.
This repo is a copy of a sub-project of Armeria.
We update this PR only when a new version of Armeria is released.
Could you reopen this PR to the https://github.com/line/armeria? 😅

Hi @opencroco, thanks for adding a nice example.
This repo is a copy of a sub-project of Armeria.
We update this repo only when a new version of Armeria is released.
Could you reopen this PR to the https://github.com/line/armeria? 😅
No problem.

Closing in favor of https://github.com/line/armeria/pull/3195


lib: limiting a burst of outgoing packets

"QUIC draft-32 7.7" says:

Sending multiple packets into the network without any delay between
them creates a packet burst that might cause short-term congestion
and losses.  Senders MUST either use pacing or limit such bursts.
Senders SHOULD limit bursts to the initial congestion window; see
Section 7.2.  A sender with knowledge that the network path to the
receiver can absorb larger bursts MAY use a higher limit.

When I test quiche in a high bandwidth/low rtt environment such as localhost,
cwnd can grow very quickly and can create a lot of packet sent
when 1) many sender packets are acked on once 2) try to recover many losses.
This PR implements limiting outgoing packet burst as recommended in the
draft. Here we limit total number of outgoing packets in a single send() loop
to the initial congestion window. When send() reaches a burst limit,
now Error::Again will be returned, so it's up to application to flush
current packets and check if there is incoming packets, or can continue
to allow bursting.
Also note that I added the limit on the send(). Such limiting burst
can be done in the application itself, but it provides more general
support and all quiche application can use same burst limiting.

Closing - this is better to be implemented in the application


Invalid Layout Should parse partly

If we made a typo or forget to include some NLog extensions, there is a change that logging won't work at all! e.g. setting the Message of a filetarget on {logger} {messagge} (notice the typo), than the filetarget won't log anything!
This is unneeded and now we are skipping the invalid parts. The invalid parts are replace with an empty string.
If throwExceptions or throwConfigExceptions is true, there will be still an error thrown

This change is

Current coverage is 76% (diff: 100%)

Merging #1583 into master will decrease coverage by <1%

@@             master      #1583   diff @@
==========================================
  Files           270        270
  Lines         16413      16423    +10
  Methods        2621       2621
  Messages          0          0
  Branches       1787       1788     +1
==========================================
+ Hits          12522      12525     +3
+ Misses         3488       3485     -3
- Partials        403        413    +10

Powered by Codecov. Last update 7d8305d...e78bc1c

Maybe add in the future the option to to set the option for replacement: empty (current), space, error, exception (enable throwExceptions)


Cannot load some giveaways because Chat not found

The reason of #49 is that because cannot load giveaways when user have not communicated with bot

I can store the name when user clicking on button and then mention him with this name

As I see, this is telegram bug, closing issue, because it was repaired by itself and user has not interacted with bot yet.


Fix trtl bug  #1317

@barakshanii kept the setup similar to the original bug because i wanted something that will include things that are beyond hdist
thoughts ? other assertion we should include ?


Specify Function Runtime Image through Environment Variable not working

It is possible to specify a custom function docker image via environment variables for the kubeless-controller deployment. Environment variables would be for example:

NODEJS6_RUNTIME
NODEJS8_RUNTIME
...
However, there seems to be a bug in the corresponding go coding at kubeless/langruntime.go GetFunctionImage lines 148 - 154. In particular the runtime information version is not taken into account.

I could provide a fix for this bug.

please go ahead 👍

close via #518


Topology should default to none

Currently the topology options in the operator are standalone and leader/follower, we need to add an option of no topology. The default option in Habitat is none and the operator should default to that as well, which means:

the difference between standalone and none is that none will never update itself

See further discussion for this here.

But also consider https://github.com/kinvolk/habitat-operator/pull/114#issuecomment-338136458. i.e. do we really need none?

@asymmetric maybe someday soon the difference between standalone and none will make a difference for operator as well? I guess best just map it exactly already?

Yeah, no strong feelings against it, 👍.

Cool, so we need to remember to also add the 'none' topology to the k8s exporter cli after we add this.

Protip: create an issue for that and add it to the board.

We we were informed by Habitat folks, there is no "none" topology and default is "standalone".


Upgrade Ruby to 3.1.x

Why
There is an attempt to upgrade it on https://github.com/nimblehq/rails-templates/pull/312
But there is an issue.

/.asdf/installs/ruby/3.1.0/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:430:in `visit_Psych_Nodes_Alias': Unknown alias: default (Psych::BadAlias)

After investigation, I found it is from figaro gem.
from /.asdf/installs/ruby/3.1.0/lib/ruby/gems/3.1.0/gems/figaro-1.2.0/lib/figaro/application.rb:60:in `parse'
from /.asdf/installs/ruby/3.1.0/lib/ruby/gems/3.1.0/gems/figaro-1.2.0/lib/figaro/application.rb:56:in `block in raw_configuration'
from /.asdf/installs/ruby/3.1.0/lib/ruby/gems/3.1.0/gems/figaro-1.2.0/lib/figaro/application.rb:56:in `raw_configuration'
from /.asdf/installs/ruby/3.1.0/lib/ruby/gems/3.1.0/gems/figaro-1.2.0/lib/figaro/application.rb:64:in `global_configuration'
from /.asdf/installs/ruby/3.1.0/lib/ruby/gems/3.1.0/gems/figaro-1.2.0/lib/figaro/application.rb:32:in `configuration'
from /.asdf/installs/ruby/3.1.0/lib/ruby/gems/3.1.0/gems/figaro-1.2.0/lib/figaro/application.rb:42:in `each'
from /.asdf/installs/ruby/3.1.0/lib/ruby/gems/3.1.0/gems/figaro-1.2.0/lib/figaro/application.rb:36:in `load'

This is because on Ruby 3.1.0, it comes with Psych 4 - https://www.ruby-lang.org/en/news/2021/12/25/ruby-3-1-0-released/

Psych 4.0 changes Psych.load to use safe_load by default. You may need to use Psych 3.3.2 for migrating to this behavior. [Bug #17866]

In the issue, they explained that now YML is loaded with aliases: false by default. So when the app tries to load Figaro's config/application.yml, it failed because in that file, we're using alias. To fix we need to pass aliases: true when loading the config just like they've done on Rails.
So in order to upgrade to Ruby 3.1, we need to have this issue fixed on figaro. I'll open the issue. But if no one responds, we will need to fork or look into other alternatives.
Who Benefits?
developers

@rosle I see that the Figaro gem did not get any update since 3 years. Shoud I create an issue about removing this gem from our template (and using database.yml and .env instead)? :)
This would unlock the upgrade from Ruby 3.0 to 3.1 and maybe 3.2 🥳

@rosle I see that the Figaro gem did not get any update since 3 years. Shoud I create an issue about removing this gem from our template (and using database.yml and .env instead)? :)
This would unlock the upgrade from Ruby 3.0 to 3.1 and maybe 3.2 🥳

Yeah 😂, Seems there won't be any new version released soon. I think maybe we can remove it for now to unblock this. And later we can introduce a new one maybe dotenv. 🙆♀


Pagefind returning undefined

After running npx pagefind --source public/ pagefind returns undefined for every search I do.
https://pagefind.app/docs/api/

npx index response
[Building search indexes]
Total:
Indexed 2 languages
Indexed 821 pages
Indexed 1645 words
Indexed 0 filters
Indexed 0 sorts

For anyone else that has this issue: It's because google chrome console doesn't return the same results as firefox's.


CIP-ShawnMcMurdo-CurvePledgeBenefit

Here is my initial CIP for modifying the reward equation to use a curved pledge benefit factor.
Let me know if I did anything wrong oryou have any feedback on the CIP itself or it's contents.
Thanks!

This sounds like a good idea that definitely worth more attention. However, I am a bit lost at the point when crossover point is introduced. Maybe some sort of graph visualization will really help more readers to understand. Although it could be done later, I also think a formal mathematical proof that the curved pledge mechanism will reach a Nash equilibrium is going to make the case more compelling.

Although it could be done later, I also think a formal mathematical proof that the new curved pledge mechanism will reach a Nash equilibrium is going to make the case more compelling.

A) Making a formal proof is pointless if the gatekeepers don't even bother to react.
B) The proof is already pretty much present in Reward Sharing Schemes for Stake Pools, as long as pledge benefit function is growing up to the k for actors who want to gain the most influence over the system and achieve olygopolic stake of control, the only thing this changes is the pace, as long as motives are the same as assumed in the beforemention paper, outcome is also the same.

Thanks for the reply cffls!
I will try to come up with a visualization of the pledge benefit vs pledge graph showing crossover but it may take me a little while to figure out how to do that.
Also, thanks Mark for explaining about the proof! That was my intuitive understanding but mathematical proofs are beyond my capability.

Hello
I am not a programmer or mathematician, but I am a pool operator for Cardano (MOST) and several other projects. What I wonder most about the way Cardano approaches this is not so much what is being paid as incentives for staking and prevention of Sybil attacks, which seems solid. What I believe is missing is incentives/penalty mechanisms for operating poor performing relays and BP Nodes.
Currently, if you have a large following, you can set up a pool (or Multiple pools) at a very low margin, set up a relay to feed those block producers and be able to produce blocks.   You can do this with a single relay or 2 and keep operating costs low. Under the current scheme, a 10,000 stake will be rewarded at a set ROI. Number of blocks produced is not a concern as long as the pool produced what was expected. With multiple pools, you can make a good profit for the 340 minimum epoch charge.
For a small pool operator, you can set up a pool and even if you have a 50k to a 400k pledge, you are unlikely to produce a block. So a 10,000 staker to my pool will not be rewarded. In my case, I set up a block producer and 2 relays all at 4 Processor/ 8GB RAM. I have a 50k pledge and another 30k staked from my wallet (Over 10k investment)  My relays and block producer are functioning at the same level as any pool, yet none of my stakers would have a chance of getting that reward.
With the emphasis on decentralization, it would seem to me that if that hypothetical 10k stake would be rewarded the same in any of the top 25 pools, why should it not be rewarded in a smaller pool. Currently there is no measurement on how a pool performs relative to connections. If we wind up with only 25-50 viable pools, the network can be susceptible to several different types of attacks.
My point is if we treat a 10k stake the same as long as it is in a large pool, why not put emphasis on utilizing the infrastructure of the small pools and build a bigger network. In the Loki project, block creation is done in listed order. You produce a block and then go to the bottom of the list. They measure uptime performance and penalize the node for missing uptime proofs. The penalty can be severe, 30 days locked out of being able to stake for the operator thus no rewards.  With Cardano, there are many more blocks in an epoch, so you could have multiple lists, putting the largest pools on a smaller list, and small pools on a large list, and then selecting the top pool on a list in a rotating manner.
Setting metrics around network performance and going to a listed approach may be a possible solution for Cardano. You can still keep the same reward formula’s and treat every stake the same, reward good performance and set a requirement for two relays. Eliminate the minimum epoch charge, while setting a minimum margin charge. This way, if you want to set up a charity pool or a small pool based on limited resources your entry point won’t be blocked by the fact you need to attract several million ada, you get more pools participating and you utilize everyone in the community who wants to participate.
Thanks for reading, I only want to make Cardano a better place!

@Danmcg86 while change in reward-sharing scheme would be relatively simple change with simple evaluation of impact, what you're proposing is a major change in consensus algorithm rules, it is also less secure (as the schedule or as you call it ordered list is known ahead of time to all participants), Cardano works with Ouroboros family of consensus protocol, specificaly Ouroboros Praos used on Cardano mainet, there are also further itterations of Ouroboros consensus such as Ouroboros Chronos and Ouroboros Crypsinous.
If the leadership schedule is not known to the network ahead of time, punishing anything like a missing a block production slot is obviously not easy and would require extensive research, what you are proposing is similar to the initial design of Ourobors which utilized Multi-Party Computation in previous epoch (n-1 or n-2, I am not sure anymore) to determine a leadership schedule for epoch n, while it had certain upsides over the Verifiable Random Functions utilized in the current algorithm, reverting back to that would be technological a step back.
This discussion is focussed on the incentives (reward sharing scheme) and sybil protection which you can refer to in the preivously linked paper.

Thanks for your response. I appreciate it. I was trying to state that I see some issues with the way the current implementation is unfolding and I believe that some incentives need to be looked at. As I stated I am not a programmer and would not propose any algorithm change. I wanted to give feedback from what I am seeing as a new SPO. I really believe in the project and wanted to give some perspective in a formal setting as opposed to a chat forum. I am confident that the team will find a way to make the proper changes. It is very early in the Shelley era and I think many of these issues will be resolved.  I do appreciate your feedback and appreciate all of the work put into the project by all the teams.

I hold the opinion, even before implementation of shelley mainnet, that linearity is a flawed approach

agree that private pools do not make the network more secured and are rewarded unfairly vs all the SPO who are really the backbone of the network. These unfair reward schemes do not help Cardano as a projects, not only for the obvious objective reasons, but also because this could be used by competitors to put Cardano under a bad light.

it does not take into account sweet spot of pledge for SPO; a heavily non-linear max rewards vs pledge in the interval 0 pledge to 300-500k pledge could be the solution. After that, and up to max pledge , a very easy slope could be used.

Linearity is too simplistic, and does not discentivize opportunistic behaviors of some SPO who have a large following and thus take advantage to run a large number of pools using a low pledge in each. This goes against centralization: 100 operators each running 10 pools vs 1000 each running 1 pool.

It promotes a race to the bottom, because  the potential reward of a pool with 0 pledge and another with 500k pledge is only an insignificant 0.2-0.25% (it should be at least 1% of difference, which will incentive SPO in concentrating efforts, marketing and financial resources in a single pool, instead of running several at much lower fees)

I agree that IOHK mathematicians & programmers should pay more attention to these types of proposal, not to take them verbatim ofc, but at least to consider the underlaying ideas in a serious manner. Dismissing an idea as inferior has no place in the world of open source and decentralized blockchains

agree that private pools do not make the network more secured and are rewarded unfairly

You are the only one arguing that, I believe it is a false statement, private pools do make the network more secure as the high network value (and thus network security) is in their selfish interest. Which is actually why I argue that the pledge influence should not be calculated as absolute value regardles of ratio between pledged amount and total delegated stake.

I agree that IOHK mathematicians & programmers should pay more attention to these types of proposal, not to take them verbatim ofc, but at least to consider the underlaying ideas in a serious manner. Dismissing an idea as inferior has no place in the world of open source and decentralized blockchains

I don't believe anyone would imagine this will be how CIP process will look like, as per CIP1 we should be in a phase Wait for approval and/or feedback from the CIP editors, how long does that suppose to take? Proposal is here for 2 weeks yet, nobody from the edditor community bothered to provide feedback.
@crptmppt, @KtoZ, @SebastienGllmt, @dcoutt, as per beforementioned CIP1

CIP editors should strive to keep up to date with general technical conversations and Cardano proposals

How is up-to-date defined in the context of CIP1? It has been mentioned in one of the AMAs by CH that the rewards sharing scheme has been looked at during a Chief Scientist Meeting, has this proposal been considered (he was not specific as to what proposal has been a subject of that meeting)? Are meeting minutes available? What are there any concerns to be addressed?

Here are 2 graphs that show the pledge benefit vs the pledge amount.
Both of these are for the example parameters of curve_root = 3 and crossover factor = 8.
The first shows the full range of pledge amounts.
The second shows only pledge amounts up to 1m ADA.

Hi @shawnim - quick note to say the CIP is being noticed and we hope to loop back in one of the upcoming meetings to review..  Meanwhile grateful that the conversation is occurring naturally! The CIP process is for now a very asynchronous and careful process - and priority was originally given to internal efforts needed for collaboration and publication - Expecting further thorough review/feedback here soon!

@crptmppt Thanks for the status update!
I look forward to any feedback and discussion.

@shawnim BTW my proposal can be elegantly combined with your proposal if you'd like, we can discuss that off-line and make a joint proposal.

I am not mathematician too, but everything that helps cardano descentralisation and more opportunity of rewards to small pools should be consider seriously. Currently there are many pools that are struggling. I've heard already bad comments or dissapontments and that is not health for the entire ecosystem. Imagine that this is just the begining and there are already bad vibes between small pools (the majority, and the core of the network). So in order to prevent more dissapontments between in the ecosystem these proposals need to be analized as soon as possible. Hope CIP can be analized and taked in count.

Thank you Shawn for coming up with graphs! It shows that the pledge amount has higher influence on rewards in lower range, while the influence decreases as the pledge increases.
I think an another important aspect of the issue, other than defining the reward function, is that we need a more transparent process to determine the value of these parameters (e.g. curve root, cross over factor).
Here are some topics I would like to see being discussed:

How do the chosen values impact either positively or negatively on small or big pools? What is the definition of a small or big pool?
What group of pools benefits most from the decision?
Does the most benefited group represent the majority of pool operators?
What defines majority ? e.g. the number of pools v.s. the stake controlled by pools.

There are definitely better questions that are not in the list, please help add to the thread.

I think an another important aspect of the issue, other than defining the reward function, is that we need a more transparent process to determine the value of these parameters (e.g. curve root, cross over factor).

I haven't done a former analysis of this but intuitively I would say that if the initial proposal from @shawnim is adopted alone, these numbers need to be a moving target, just like there is a race to the top in PoW mining power, there must be a race to the top with pledge (for pools that accept public delegations), which is why I made my first comment.
I would not consider the proposal to be a solution but rather a temporary bandate, the initial model (linear pledge influence) was good until it got skewed by minimal fixed epoch costs.  There is a reason why PoW employs dynamic difficulty adjustment.

Hello guys, is it possible to change the formula 1 day per week in order to have a complete random distribution of rewards (a lottery) because with the formula only pool with high pledge or stake are rewarded ?

There is many pools at 0 block minted today ! They will quit i think.

@mark-stopka I think your idea is definitely worth considering but I think it is better to do it as a separate CIP. It may make it more complicated and contentious to
join them.
@stakepoolplace That is an interesting idea! I think it would be a big change from a design goals perspective that would need discussion and research. Perhaps it could be a percentage of blocks that are lottery blocks between all pools that have at least a small minimum pledge.
You should create a separate CIP for this.
@crptmppt It has been 11 days since you said "we hope to loop back in one of the upcoming meetings to review." and 24 days since I submitted this CIP. Considering that
the first step is to simply review that the CIP is properly submitted and change the status to "Draft" and has nothing to do with the content, I don't understand why
this is taking so long. It would be helpful if there was a defined timeframe for this initial step and some sort of regular schedule of review or status update after t
hat.
@KtoZ @SebastienGllmt
It has been more than 2 months since I proposed this idea but there has been no response from anyone at IOG.
I would love to see any kind of feedback on the idea and/or implementation alternatives even if it was as simple as "It is an interesting idea but we are too busy to consider it until after ."
@brunjlar @romainPellerin @solegga

@shawnim
The CIP process is intently slow - meetings happen every two weeks and we're still tweaking the process (please see meeting notes for visibility). We're improving the comms as we go, I know this particular proposal has had visibility all the way up and have personally brought it up.

@crptmppt Thanks for the update!
Just want to know that things are moving forward and not ignored.
Appreciate the response.

Hi, here a possible formula to calculate rewards, before applying the apparent performance factor, basis on a relative pledge concept introduced by @mark-stopka in his first comment.

This formula still takes into account the "k" parameter (in the variable sigma' in case pool stake/total stake exceed 1/k) as a threshold to avoid centralization. In case of low fixed costs "k" parameter could be unnecessary.
Through this formula the pool owner receives full reward (before applying apparent performance factor) in case his pool stake corresponds to the owner pledge and the pool is able to produce at least one block.
As attachment an excel file to test some simulations.
CIP12 relative pledge simulation.xlsx

I like the general idea because it has "desired" orientation points
From my understanding when we talk about reward benefits this is related to increasing/lowering a0. Not anymore in a linear way. But as a sum of all pools it might change significantly because pools are incentivised to choose pledge amounts with higher reward benefits.
But this does not only affect pools with a currently low pledge. We also need to think about the effects of very large players.
The proposed curve looks logarithmic. It might worth think about a 3-degree curve to deal with participants who can fully pledge their pool. This should motivate them to run fewer pools at full pledge instead of splitting them up to xx high pledged (desirable) pools able to attract a lot of delegations. This would actively kick out numerous other pools from the k-area and significantly work against decentralisation.

^ this is just a quick sketch but generally said the benefit for this big whales should be slightly larger then what they can achieve with competitive margins by collecting huge amounts of delegations. They inevitably will earn more rewards then, but not at the cost of binding too much delegator stake
For sure there is no perfect way to design this curve. A whale holding 30-80% of saturation point still is motivated to split his pools up. But significantly increasing reward benefits to early (eg from 50% of saturation) increases the risk whales able to fully pledge multiple pools will split this up with all the undesired effects.

Thanks for the thoughtful response @gufmar !
It is worth exploring with some various scenarios to understand whether this is necessary.
The superwhale who can fully saturate their own pool would be taking a risk to accept lower pledge benefit rewards from multiple smaller pledge pools in exchange for the fees they could make from potential delegators.
FYI, the rich list shows the following high value addresses:
ADA
4 250m+ (1.39b, 1.38b, 1.09b, 604m)
7 211m+ (k = 150 sat)
9 159m+ (k = 200 sat)
14 127m+ (k = 250 sat)
39 100m+ (15 108.66m)
58 50m+ (9 64.11m)
Many of these high value wallets belong to IOG, Emurgo, CF, Charles, etc.
Even with k set to 250 there are only 14 wallets that could fully saturate their own pool.
My intuition is that the curve up at the high end is not needed but it's certainly worth evaluating different scenarios of pledge and delegation to confirm.

@dcoutts mentioned that this proposal will require a Hard Fork Combinator event but I think we have a couple of tose coming up in the next few months to piggyback on.
If this had some unforeseen undesirable effect, we would not need a HFC event to remove it as it is possible to easily restore the original behavior simply by setting the curve_root parameter to 1.

Thanks to Chris from STR8 pool for bringing this to my attention.
My use of the word private refering to whale pools was confusing. What I mean is that currently a fully saturated pool that contains only the owner's pledge receives 30% more rewards than a fully saturated pool with no pledge and 29% more rewards than a fully saturated pool with 5m ADA pledge.

Even with k set to 250 there are only 14 wallets that could fully saturate their own pool.

I know the number of address sizes as I curated https://cardano.bytemaniac.net/istoria/ since 2018 in order to show the evolution over time.
The issue IMO is not when 14 super-whales fully pledge their pools. Indeed this is what we want, as we can`t do anything else and better. The issue arises when these super-whales have incentives to register 140-200 pools pledged at ~10%.
And by increasing k, and so lowering the saturation I expect to see almost the same effect. with k=500 we probably could see around 150 fully pledged pools, or again something like 500 pools pledged at ~10%
The least bad and IMO only acceptable way is to give the super-whales their own very profitable spot, where they prefer to stay and don*t cause damage to all lower sized fishes.

@gufmar I think the question is "How much is enough reward for pledging to keep super whales from creating many pools?".
It would be interesting to ask them since it is a tradeoff between the safe bet of pledge benefit rewards versus the risk of getting enough fees to offset the lower pledge rewards from multiple pools.

Really nice write-up; comments have been very helpful as well.
I am actively reviewing this proposal.
A couple dependencies to point out:
1 - this proposal involves a "hard fork"; it is a longer lead time that a parameter change
2 - the pledge benefit scales based on the max size of a pool (set with 'K'); there is some dependence on that change.

This may make sense, maybe not, just thinking out loud. Maybe the statistical mode could help us figure out how the curve should be set. We could sort the pledge amounts currently on the block chain each start of an epoch and then remove the lowest pledged pools till it matches k. At this point we could then find the mode of the left over pledges and determine at which point the curve should transition from an aggressive slope a more subtle one.

This may make sense, maybe not, just thinking out loud. Maybe the statistical median could help us figure out how the curve should be set. We could sort the pledge amounts currently on the block chain each start of an epoch and then remove the lowest pledged pools till it matches k. At this point we could then find the median of the left over pledges and determine at which point the curve should transition from an aggressive slope a more subtle one.

@Danmcg86.
Let's see if we can create a block producing pool of MOST.
Today the group I work with together on Cardano will delegate about 1.3M ADA to your pool (active from Epoch 211) for at least 8 Epochs.
Now I am staking at BLOOM and 1PCTx (various pools)  My overall average of the last month is 5%. (about 900 ADA for 1.3 M ADA Delegation
It would an be interesting experiment to see what happens. also on Pooltool

I think, to prevent sybil attacks and too prevent one user/company have many pools ( both don't work efficiently to decentralize the system), to have a mimimal pledge of 100K (value about $ 10k) . That is a fair amont where we talk about running a business. Besides that cooperation between pool builders/operators and investors is possible (although a smart contract would be advisible).

Pools need to be registered somewhere. Is there no way to limit the number of pools by checking any given data, given the fact that around the globe governments are thinking of ways to legalize the use of Crypto currencies but still get all tax paid on profits on Cryptos. I am aware that super whales could start multiple companies but the costs of having multiple companies, just to be able to run multiple stakepools to get higher rewards looks not logical to me.

K should be viewed as a minimum number, not a target number of pools
We do not want to be using K in a way that forces convergence (beyond what
is already implied.)
This is particularly important at low levels of K, aka 150: killing off
850+ stake-pools would be an extremely short sighted thing to do
Right now, pools are incentivized to split into smaller pools with high
leverage
You return on investment (ROI) is of the form ( A*(1-x)  + B*x ) / x, where
x=proportion of the pool pledged
i.e., You get a return from proportion of the pool you don't (the variable
fee) plus plus a pledge benefit from the part you do own, then divide this
through by how much money you had to invest
Things to consider, no particular order:

We don't want funds running "private pools" that are fully pledged, and
distributing rewards like tezos "bakers", to become the de-facto standard
There is a limit to where we can push A0 too.

Changing K has a fairly large impact; the pledge reward is for a "fully
saturated" pool, so increasing K (reducing maximum pool size) is a linear
increase to value of pledge

"High leverage" pools (i.e., lots of delegation to pledge) are fairly
problematic - we want pool operators to have some skin in the game.

Higher amounts of pledge unlock more rewards for everyone, so also
beneficial for everyone

Once a pool gets beyond about 10% pledge, the benefit becomes fairly
linear. The rewards for adding more pledge outweigh the loss from less
delegation.

We probably are not THAT concerned about a 30% pledge pool splitting
into two 15% pledge pools; while we might prefer a pool stay pledged to
share delegation around, this is not really "sybil" behavior either

The really problematic area is the low pledge pools... scaling like
(1-x)/x ... as pledge goes very small the ROI increases massively,
incentivizing you to create more low pledge pools rather than adding more
pledge

On Sat, Sep 26, 2020 at 8:08 PM Robert Stanfield<EMAIL_ADDRESS>wrote:

This may make sense, maybe not, just thinking out loud. Maybe the
statistical mode could help us figure out how the curve should be set. We
could sort the pledge amounts currently on the block chain each start of an
epoch and then remove the lowest pledged pools till it matches k. At this
point we could then find the mode of the left over pledges and determine at
which point the curve should transition from an aggressive slope a more
subtle one.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/cardano-foundation/CIPs/pull/12#issuecomment-699535974,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQEOU7ZEYQQKWSNLCP4ZNMLSHY32JANCNFSM4P4NXLQA
.

@shawnim I finished initial modeling on the economics of the proposal, forwarded the results to our formal methods team at IOG for review. I will reach out to you next week to discuss (it's getting late on a Friday, just wanted to let you know this was in fact moving.)
@mark-stopka your suggestions were also evaluated as part of my analysis, your feedback here was very helpful.

@Colin-Edwards-IOHK Thanks for your work on this!  Really appreciate it.

@shawnim Given we are still establishing a process for CIPs; your feedback would be really appreciated, specifically on how to handle this kind of thing better in the future. I'd personally like to see a bit of a round-table discussion on "the Cardano Show" or something. As we shift to more community engagement I want to make sure we get the lessons out in front of people!

Have you formalized my proposal as well? My scheme is almost the same as I
intend for tehelemtry sidechain, it would save me time and money if I could
reuse your model or use it as a starting point.
Please see dCloud on Project Catalyst IdeaScale page...
--
Sent from mobile
Best regards / S pozdravem,
BSc. Mark Stopka, BBA
Managing Partner @ PERLUR Group
mobile: +420 704 373 561
website: www.perlur.cloud
On Fri, Oct 9, 2020, 18:24 Colin<EMAIL_ADDRESS>wrote:

@shawnim https://github.com/shawnim I finished initial modeling on the
economics of the proposal, forwarded the results to our formal methods team
at IOG for review. I will reach out to you next week to discuss (it's
getting late on a Friday, just wanted to let you know this was in fact
moving.)
@mark-stopka https://github.com/mark-stopka your suggestions were also
evaluated as part of my analysis, your feedback here was very helpful.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cardano-foundation/CIPs/pull/12#issuecomment-706276985,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEKMP3F2KUGR4ZRSJ7OXSPLSJ42L5ANCNFSM4P4NXLQA
.

I would love to participate in such discussion, I believe my involvement
not only in this CIP gives me enough insight 9nto the CIP process to be
able to use my knowledge of Lean and 6Sigma methodology to improve upon the
current CIP process.
--
Sent from mobile
Best regards / S pozdravem,
BSc. Mark Stopka, BBA
Managing Partner @ PERLUR Group
mobile: +420 704 373 561
website: www.perlur.cloud
On Fri, Oct 9, 2020, 18:38 Colin<EMAIL_ADDRESS>wrote:

@shawnim https://github.com/shawnim Given we are still establishing a
process for CIPs; your feedback would be really appreciated, specifically
on how to handle this kind of thing better in the future. I'd personally
like to see a bit of a round-table discussion on "the Cardano Show" or
something. As we shift to more community engagement I want to make sure we
get the lessons out in front of people!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cardano-foundation/CIPs/pull/12#issuecomment-706283814,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEKMP3HOPVOOOEHJOMHLTYTSJ44ABANCNFSM4P4NXLQA
.

@mark-stopka yes, your feedback was included in my analysis, hopefully fairly ;-)
Speaking of round-tables, it might also be useful to get you, me, Shawn, some of our research team (Akaterini? Lars?) together to talk through the implications of the a0 change as well (maybe separately to improvements the CIP process, although maybe at the same time.)
I'll freely admit having a agenda here; we need to practice giving up some control over the system. As we are starting out the CIP journey, I hope we can use this as starting off point on doing that well: having a real dialogue about the changes being proposed, giving key influencers a forum to talk about their ideas.  Getting a decentralized frame work to work, where decisions can still get made promptly, is a work in progress. I am hoping not to just get this change done, but also done in a way that helps future changes go more smoothly.

@mark-stopka yes, your feedback was included in my analysis, hopefully fairly ;-)
Speaking of round-tables, it might also be useful to get you, me, Shawn, some of our research team (Akaterini? Lars?) together to talk through the implications of the a0 change as well (maybe separately to improvements the CIP process, although maybe at the same time.)
I'll freely admit having a agenda here; we need to practice giving up some control over the system. As we are starting out the CIP journey, I hope we can use this as starting off point on doing that well: having a real dialogue about the changes being proposed, giving key influencers a forum to talk about their ideas. Getting a decentralized frame work to work, where decisions can still get made promptly, is a work in progress. I am hoping not to just get this change done, but also done in a way that helps future changes go more smoothly.

Hi @Colin-Edwards-IOHK, I am happy to participate in any round-table, I would also like to see (even privately under NDA) your assessment of my proposal comments / ideas as it is a foundation of the dCloud side-chain...
I was told you spoke highly about my input, so I appreciate that!

@Colin-Edwards-IOHK I would be happy to participate in any discussion of the CIP process or of particular CIPs.
It would be great to have some dialog with the IOG researchers since they have been publicly silent on this and the Non-Centralizing Rankings CIP.

As an update to this, my analysis is being reviewed by Elias, Lars and Katerini from the IOG research team. They will be focusing on the game-theory analysis; depending on their feedback we might have a couple more iterations. The research paper from 20 June, 2020 came to different conclusions than I did, so it's still a conversation not a finished decision, but it is an active conversation.
(Off-Topic: I have asked Tim/Ben to get wider engagement from the community regarding the rankings CIP. I personally see no reason why a requested measure should not be incorporated in Daedulus if it was popular enough. There is a development pipeline to work around but I hope to at least get some clarity as to when/how a decision will be made for that soon. It feels more like a "daedulus the wallet" issue, not a "cardano the blockchain" issue, so I have not been very involved.)

Once again an update to say we are still actively working on this. The internal discussions between myself and our research team are progressing, think we have identified a strategy that everyone seems comfortable with. I am working on writing that up, once that gets reviewed, will bring it to the wider community for review/discussion as it has some changes to the original CIP above.

Thanks @Colin-Edwards-IOHK for the updates!
Really appreciate your open communication.

I am still working on a more formal response to all this; so apologies for the lack of polish. (Our game-theory researchers are also working through it still as well.) I mostly just wanted to give you a bit of color on what we were thinking about and why things are taking a long time.
In the initial statement you had two items: [1] increase incentives for pool operators to pledge thus increasing Sybil attack resistance while [2] reducing exorbitant rewards for private and whale pools to a more reasonable amount. I strongly agree with the first, it's very consistent with the philosophy and modeling work that has been done. I don't agree with the 2nd point, I'll briefly go over that, but it's a bit of a rabbit hole of a discussion, so it'll be a bit of hand-waving to move things along.
In the chart below there are the additional rewards that pledge attracts in an otherwise unsaturated pool at K=500. It's really small; so small that it is totally overwhelmed by things like block creation which has a large component of random noise. I strongly agree with the idea that this pledge benefit needs to be significantly increased to affect "human decision making". I've also sort of taken the approach of focusing on this one aspect of your CIP - it seems like the most important thing to resolve.

In terms of the "Return on Investment" for bigger pools; we don't have a lot of room to do stuff there. There is a huge trade-off between whether exchanges, funds, whales, etc. lock up their funds in private pools or use the pledge to dominate the SPO business. The main thing to get out of the chart below is that on the right hand side it needs to be either flat or upward curving or else exchanges will all actively start competing for delegation.

So to recap:

Because of that, I have been looking into alternate forms of the rewards.
There are a couple flavors of things I have tried; the most promising is just added a flat pledge benefit by changing the a0 formula to have an intercept and a slope. That intercept can be zero, which keeps the existing behavior, and goes all the way to totally flat for a something more along the lines of Mark's comments. It converges to the existing behavior for saturated pools (which makes it consistent with all the research on stable Nash equilibriums.)

A couple pictures to show how this changes for different types of pools
Fully Saturated

Only-Pledge

A flat benefit of between 5% and 25% tend to behave very well in my simulations, which base behavior off things like "present value of cash flows". In terms of running a staking business, having a bunch of pledge immediately more meaningful, has higher earnings for pools, causes real differentiation on the pool dashboards other than by dropping the variable margin to 1% or less.
I have looked at the long-term impact on the reserves, but since the main beneficiaries are small pools with relatively low levels of pledge on a "percent of a saturated pool" basis, it's pretty minimal, different milestones a couple months earlier over a decade.
I know it's gone a bit far afield from the initial CIP!

Thanks @Colin-Edwards-IOHK for all of your work on this!
I really appreciate the updates.
What you have described all makes sense to me.
I'm not tied to my original proposed solution for making pledge meaninfful. Only that something is done to make it meaninfful in a fair way.
As for reducing the top end rewards I understand the point about encouraging exchanges to fully pledge pools rather than create many pools and try to attract delegation.  So on that I defer to your (and the research team's) expertise on finding the right balance of top end rewards.
Happy to see progress on this!

@Colin-Edwards-IOHK Very cool post, sorry if this is tangential but I was wondering about your comment about exchanges using their funds to dominate the SPO business. It does make sense to me that we'd rather see exchanges self-saturate via pledge, but is there also concern that rewarding exchanges for doing so will allow them to offer higher rewards for people to put their ada on an exchange and hold it there instead of in daedalus and staking to others?

@Colin-Edwards-IOHK , thanks for your work on this
I understand your point about exchanges too and it's a very good one.
What is not so clear to me is about the left side of the graph. I was thinking that one of the purposes of @shawnim 's proposal was to find a way to amplify the effect of a0 also on the lower range of pledges between 0 and 2M, where most of operators are lied on in order to push the increase of pledges and, as consequences, give operators more rooms to increase fees while remaining competitive to zero-pledge/zero-fee pools.
If I read correctly graphs of your proposal, and I doubt it, it seems to me that the a0 effect is even more mitigated for the lower pledge range of 0-2M. Am I wrong?

@Colin-Edwards-IOHK
I would like to thank you for looking into this important matter.
I understand that we might have a problem with incentives if larger pledges in the network earn less rewards than smaller ones (where the majority of SPOs would feel comfortable operating). So I share your view above...
I also see that the propose reward function above, starts off all pools at 15% ROS. The differentiated returns don't kick in until the pool has a pledge=40% of saturation.
This is a problem because:

It does not solve the problem of low pledge pools, as it does not introduce differentiated returns till the pool is 40% pledged.
At k=1000, which is a target state, a pledge = 40% of saturation equals 13M, which only one SPO may be able to afford out of 1k+. Even then the motivation to pledge that much remains questionable due to the steepness of the curve (or rather lack thereof).

So I have been testing different scenarios with the original function proposed by @shawnim and may have come with something that would allay your earlier concerns with it, while providing the necessary difference in returns in the lower range of pledge distribution.
Here is the sensitivity table with graphs comparing the results of the function with the status quo.

I have also attached the excel file for your convenience.
shelley_rewards_wdv.xlsx
Thank you again,
Umed Saidov, CFA [SKY]

@Colin-Edwards-IOHK Very cool post, sorry if this is tangential but I was wondering about your comment about exchanges using their funds to dominate the SPO business. It does make sense to me that we'd rather see exchanges self-saturate via pledge, but is there also concern that rewarding exchanges for doing so will allow them to offer higher rewards for people to put their ada on an exchange and hold it there instead of in daedalus and staking to others?

@prometheus-pool @mark-stopka Remind me about Mark's idea that a0 should affect ratio of pledge and total delegated stake so big pools need to pledge more.

Exchanges can achieve largest rewards either way if they sufficiently restrict customer widhrawal policies + they have strong motivation to have people to encouraged to keep funds on exchanges, because they are then more liklely to trade which generates fees for the exchange which is the primaqry source of revenue for the exchange.

K should be viewed as a minimum number, not a target number of pools We do not want to be using K in a way that forces convergence (beyond what is already implied.) This is particularly important at low levels of K, aka 150: killing off 850+ stake-pools would be an extremely short sighted thing to do Right now, pools are incentivized to split into smaller pools with high leverage You return on investment (ROI) is of the form ( A*(1-x) + Bx ) / x, where x=proportion of the pool pledged i.e.,  We don't want funds running "private pools" that are fully pledged, and distributing rewards like tezos "bakers", to become the de-facto standard There is a limit to where we can push A0 too. 2. Changing K has a fairly large impact; the pledge reward is for a "fully saturated" pool, so increasing K (reducing maximum pool size) is a linear increase to value of pledge 3. "High leverage" pools (i.e., lots of delegation to pledge) are fairly problematic - we want pool operators to have some skin in the game. 4. Higher amounts of pledge unlock more rewards for everyone, so also beneficial for everyone 5. Once a pool gets beyond about 10% pledge, the benefit becomes fairly linear. The rewards for adding more pledge outweigh the loss from less delegation. 6. We probably are not THAT concerned about a 30% pledge pool splitting into two 15% pledge pools; while we might prefer a pool stay pledged to share delegation around, this is not really "sybil" behavior either 7. The really problematic area is the low pledge pools... scaling like (1-x)/x ... as pledge goes very small the ROI increases massively, incentivizing you to create more low pledge pools rather than adding more pledge
…
On Sat, Sep 26, 2020 at 8:08 PM Robert Stanfield @.**> wrote: This may make sense, maybe not, just thinking out loud. Maybe the statistical mode could help us figure out how the curve should be set. We could sort the pledge amounts currently on the block chain each start of an epoch and then remove the lowest pledged pools till it matches k. At this point we could then find the mode of the left over pledges and determine at which point the curve should transition from an aggressive slope a more subtle one. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQEOU7ZEYQQKWSNLCP4ZNMLSHY32JANCNFSM4P4NXLQA .

Could we use token locking to give extra rewards to delegators (and pool operators) who freeze their funds delegated into any given pool for a given amount of time? That intuitively would drive delegators to lock their funds for a while to increase network security. It would also allow us to get rid of pledge altogether as any pledge formula rewards exchanges/funds no matter how the formula looks like. Finally, getting rid of pledge would not expose pool operators and their families to criminals who can physically try to harm them either (coming from a 3rd world country, this hits me the hardest)

K should be viewed as a minimum number, not a target number of pools We do not want to be using K in a way that forces convergence (beyond what is already implied.) This is particularly important at low levels of K, aka 150: killing off 850+ stake-pools would be an extremely short sighted thing to do Right now, pools are incentivized to split into smaller pools with high leverage You return on investment (ROI) is of the form ( A*(1-x) + Bx ) / x, where x=proportion of the pool pledged i.e.,  We don't want funds running "private pools" that are fully pledged, and distributing rewards like tezos "bakers", to become the de-facto standard There is a limit to where we can push A0 too. 2. Changing K has a fairly large impact; the pledge reward is for a "fully saturated" pool, so increasing K (reducing maximum pool size) is a linear increase to value of pledge 3. "High leverage" pools (i.e., lots of delegation to pledge) are fairly problematic - we want pool operators to have some skin in the game. 4. Higher amounts of pledge unlock more rewards for everyone, so also beneficial for everyone 5. Once a pool gets beyond about 10% pledge, the benefit becomes fairly linear. The rewards for adding more pledge outweigh the loss from less delegation. 6. We probably are not THAT concerned about a 30% pledge pool splitting into two 15% pledge pools; while we might prefer a pool stay pledged to share delegation around, this is not really "sybil" behavior either 7. The really problematic area is the low pledge pools... scaling like (1-x)/x ... as pledge goes very small the ROI increases massively, incentivizing you to create more low pledge pools rather than adding more pledge
…
On Sat, Sep 26, 2020 at 8:08 PM Robert Stanfield @.**> wrote: This may make sense, maybe not, just thinking out loud. Maybe the statistical mode could help us figure out how the curve should be set. We could sort the pledge amounts currently on the block chain each start of an epoch and then remove the lowest pledged pools till it matches k. At this point we could then find the mode of the left over pledges and determine at which point the curve should transition from an aggressive slope a more subtle one. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQEOU7ZEYQQKWSNLCP4ZNMLSHY32JANCNFSM4P4NXLQA .

Could we use token locking to give extra rewards to delegators (and pool operators) who freeze their funds delegated into any given pool for a given amount of time? That intuitively would drive delegators to lock their funds for a while to increase network security. It would also allow us to get rid of pledge altogether as any pledge formula rewards exchanges/funds no matter how the formula looks like. Finally, getting rid of pledge would not expose pool operators and their families to criminals who can physically try to harm them either (coming from a 3rd world country, this hits me the hardest)

Great comments. Thanks for sharing this in the blog post also.
@Colin-Edwards-IOHK can you try to explain in simple terms what this would mean for smaller stake pools and how it may or may not impact how larger pools split?
My attempt to understand so far is more or less the following:
If the distribution of rewards (not sure is that is the same as benefit here) for smaller pledges is increased (still targeting 30% at full saturation / pledge), then the total rewards isn't changing. Just that the more successful pools will subsidize the smaller pools to allow them to bootstrap and compete? Then when K = 1000 at some point, more blocks will be created by smaller pools and provided that additional opportunity to sustain themselves until they can work towards more pledge their their community efforts/contributions?

Here's the link to the IOG blog post by Colin that talks about the IOG response to this proposal and related issues:
https://iohk.io/en/blog/posts/2021/03/04/not-long-till-d-0-day/
Looking forward to IOG publishing the details on the new rewards function.

@danhosg if interested in that vein, please pressure your facilitators at IOG Marketing to help get the "multi stake pool links" part of this CIP implemented: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0013/CIP-0013.md#specification
... along with @KtorZ 's equivalent for more articulated multi-pool delegation with JSON files: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0017/CIP-0017.md
... and provide your +1 for this already existing request to provide the now-standardised multi pool links in Daedalus: https://github.com/input-output-hk/daedalus/issues/2548
I don't know if there's a request for JSON based multi pool delegation in Daedalus, but @disassembler himself suggested it here, almost a year ago now: https://forum.cardano.org/t/cip-stake-uri-scheme-for-pools-delegation-portfolios/40594/2
My impression is that any implementation of these standards in the Cardano officially supported wallets will only be provided through relentless pressure by SPOs through their representatives at IOG Marketing.
BTW your comment doesn't directly relate to the "Curve Pledge Benefit" so I'm simply responding to your suggestion to "facilitate distribution of delegation."


Segfault building Images on 0.4

I tried checking out Images, Homebrew, and BinDeps in case something was solved recently.
  | | |_| | | | (_| |  |  Version 0.4.0-dev+6195 (2015-07-23 20:02 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 063a8bf* (0 days old master)
|__/                   |  x86_64-apple-darwin14.4.0

julia> Pkg.build("Images")
INFO: Building Homebrew
HEAD is now at eac4b0a msmtp: add --with-gsasl option.
HEAD is now at 6d4cd94 Merge branch 'staging'
INFO: Building Images

signal (11): Segmentation fault: 11
MagickQueryConfigureOption at /Users/sean/.julia/v0.4/Homebrew/deps/usr/lib/libMagickWand-6.Q16.dylib (unknown line)
anonymous at no file:0
jl_apply at /Users/sean/repos/julia/src/./julia.h:1273
jl_eval_module_expr at /Users/sean/repos/julia/src/toplevel.c:166
jl_parse_eval_all at /Users/sean/repos/julia/src/toplevel.c:574
jl_load at /Users/sean/repos/julia/src/toplevel.c:617
include at ./boot.jl:254
include_from_node1 at ./loading.jl:197
jl_apply at /Users/sean/repos/julia/src/interpreter.c:55
eval at /Users/sean/repos/julia/src/interpreter.c:212
jl_toplevel_eval_flex at /Users/sean/repos/julia/src/toplevel.c:524
jl_toplevel_eval_flex at /Users/sean/repos/julia/src/toplevel.c:471
jl_toplevel_eval_in at /Users/sean/repos/julia/src/builtins.c:552
evalfile at loading.jl:213
evalfile at loading.jl:213
anonymous at pkg/entry.jl:652
cd at ./file.jl:22
build! at pkg/entry.jl:651
build at pkg/entry.jl:663
jl_apply at /Users/sean/repos/julia/src/gf.c:1657
jl_apply at /Users/sean/repos/julia/src/./julia.h:1273
anonymous at pkg/dir.jl:31
cd at file.jl:22
cd at pkg/dir.jl:31
build at pkg.jl:64
jl_apply at /Users/sean/repos/julia/src/gf.c:1657
jl_apply at /Users/sean/repos/julia/src/interpreter.c:55
eval at /Users/sean/repos/julia/src/interpreter.c:212
jl_toplevel_eval_flex at /Users/sean/repos/julia/src/toplevel.c:524
jl_toplevel_eval_in at /Users/sean/repos/julia/src/builtins.c:552
eval_user_input at REPL.jl:62
jlcall_eval_user_input_20845 at  (unknown line)
anonymous at task.jl:91
jl_apply at /Users/sean/repos/julia/src/task.c:233
[1]    54259 segmentation fault  julia-dev

I assume https://github.com/JuliaLang/Homebrew.jl/wiki/Debugging-Homebrew.jl doesn't help? If not, we'll have to call in the heavy artillery (aka, @staticfloat).

It has been a while since I've debugged a package build, and I forgot the routine. I'll run through the debug guide and report back.

All's well after removing "imagemagick". Thanks for the wiki pointer!

Glad it was easy!


[docusaurus-plugin-typedoc]: add the ability to add a separate frontmatter for readme file.

Readme is an essential part of the documentation, sometimes it serves as the main page for docs, I want to add a separate frontmatter for a readme file, such as hiding the title, toc, and navigation, currently there's no way to do this only for the readme file, the frontmatter property applies to all the generated files.
It would be great if we had a way of specifying a separate set of standard frontmatter only for the readme.
It could look something like this
readmeFrontmatter: {
 // standard docusasrus frontmatter here
}

Thanks!

https://typedoc-plugin-markdown.org/plugins/frontmatter/options#readmefrontmatter


feat: update vendored xz to 5.6.1

Updates the vendored version of xz to be 5.6.1. Also updates the
vendor script to support the addition of SPDX-License-Identifier
headers into some files.

Thank you! So if I'm understanding correctly the license of the C files have changed? We'll need to update this repo's readme I guess.

Correct, I realized that after I made this change. I'll update the README

I just read that xz 5.6.1 has been compromised: https://news.ycombinator.com/item?id=39865810
I'm sorry, but I find the timing of this PR to be very suspicious. This repo has been dormant for 2/3 years with no PRs. But a compromised xz is released and all of a sudden there's a PR to include it here...

None of the backdoor files (build-to-host.m4, bad-3-corrupt_lzma2.xz and good-large_compressed.lzma) are present in this repo or PR though. So let's not jump to conclusions here.

None of the backdoor files (build-to-host.m4, bad-3-corrupt_lzma2.xz and good-large_compressed.lzma) are present in this repo or PR though. So let's not jump to conclusions here.

It's not out of the question that a malicious PR author would wait for an approval before updating the PR with malicious contents.
I believe GitHub flows allow for that if a repo is configured as such.

I've sent an email to 1Password security

Hi 1Password security,
https://github.com/jamespfennell/xz/pull/2 was opened by what appears to be the GitHub account belonging to one of your employees, Jared Allard https://github.com/jaredallard. The PR updates the dependency xz to a recently backdoored version (https://www.openwall.com/lists/oss-security/2024/03/29/4, CVE-2024-3094). It is not conclusive that the PR introduces the backdoor behind the CVE, but given the suspicious circumstances I believe you should investigate.
Kind Regards
Andy

None of the backdoor files (build-to-host.m4, bad-3-corrupt_lzma2.xz and good-large_compressed.lzma) are present in this repo or PR though. So let's not jump to conclusions here.

Honestly? I would consider 5.6.0 and 5.6.1 source compromised until audited. The attacker did a backdoor in the packaging but they did have repo access, so who knows if anything else is hidden inside.
For example, this commit:
https://github.com/tukaani-project/xz/commit/82ecc538193b380a21622aea02b0ba078e7ade92
Is most likely part of hiding the exploit that was in the packaging.

None of the backdoor files (build-to-host.m4, bad-3-corrupt_lzma2.xz and good-large_compressed.lzma) are present in this repo or PR though. So let's not jump to conclusions here.

Honestly? I would consider 5.6.0 and 5.6.1 source compromised until audited. The attacker did a backdoor in the packaging but they did have repo access, so who knows if anything else is hidden inside.
For example, this commit: tukaani-project/xz@82ecc53
Is most likely part of hiding the exploit that was in the packaging.

I would not only consider 5.6.0 and 5.6.1 to be compromised, that GH account signed releases for multiple years.
I'm just not a fan of jumping to conclusions on things that are not obviously (but might be) related.

This is serious!
While this is mostly incoherent blurb of links and thoughts, this vulnerability "in general" is well planned and timing of 1password personnel pushing this ASAP now sounds suspicious, while obviously it might not be related directly, as 1PW user I obviously certainly hope these are not related... But XZ is backdoored in certain versions and there is no telling yet how deep this rabbit hole goes!
List of links relating tho this backdoor:
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users
https://www.openwall.com/lists/oss-security/2024/03/29/4

The payload is only injected if the backdoor component of the build system, described above, triggered.
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
"The payload only activates if the running program has the process name /usr/bin/sshd"

https://news.ycombinator.com/item?id=39865810
https://www.helpnetsecurity.com/2024/03/29/cve-2024-3094-linux-backdoor/
So in any way, DO NOT PUSH THIS VERSION OF XZ TO PRODUCTION!!

The PR author mentions @1Password in his GitHub profile but he is not listed under https://github.com/orgs/1Password/people. Not unlikely but also something I wanted to point out here.

https://www.linkedin.com/in/jaredallard/ is a verified LinkedIn account (meaning the account owner has an 1Password/AgileBits email address). To be clear I don't think the 1Password employee is complicit in the supply chain attack. If this PR were a malicious act, it's likely due to this GitHub account having been taken over.

The PR author mentions @1Password in his GitHub profile but he is not listed under https://github.com/orgs/1Password/people. Not unlikely but also something I wanted to point out here.

https://www.linkedin.com/in/jaredallard/ is a verified LinkedIn account (meaning the account owner has an 1Password/AgileBits email address). To be clear I don't think the 1Password employee is complicit in the supply chain attack. If this PR were a malicious act, it's likely due to this GitHub account having been taken over.

Good information 👍
However, the takeover must have went unnoticed for multiple days given the timeline of this PR (open + comment 4 days apart). Which is not impossible (account owner on holiday, etc.).

I think it's best to just wait for a comment from @jaredallard. That will help clear things up.

Someone please verify - But I think this PR is unrelated to recent events and does not in fact trigger or include the backdoor that was found.
The backdoor code is only included when the original xz project (not this Go wrapper)  is built as part of a Debian or RPM package build. AFAIK this project doesn't do that. Instead this project includes the source code directly via CGO.
It is probably a good idea to follow the news to understand if any malicious code was also included in xz C sourced. I think as of today there is no reason to believe that, but that may change as people do a more thorough audit of that code.

While the immediate results is more or less engineered towards certain "this is getting built, target that", the author has had access to repository over an year.. So "we" or 1PW, needs to be extra careful what has been used and where.

Hey all, context on this change:
I've been working on building a Gentoo binary package server that I maintain on Github. I wanted an easier way to manage Gentoo binary package targets (that is to make managing my current gentoo.rgst.io site easier to operate).
As part of this, I needed to support xz archives. I always set BINPKG_COMPRESS
to xz (which makes the inner archives of a gpkg use xz) because xz has the best compression ratio. Go does not have native support for xz archives. I ran into this the last time I tried to support xz archives in code (ref). At that time, I used a native Go library. It was painfully slow. So, this time around, I went looking for other options. I saw https://github.com/jamespfennell/xz, which used CGO. As much as I dislike CGO, I wanted to give this a shot and see if performance was better.
When I looked at that repo, I noticed it easily supported updating the version of xz in use and that it hadn't been updated in 3 years. Given that I get a huge kick out of updating things, for example: on ohmyzsh and gentoo (I guess from SRE days?), I updated the submodule, ran the generate code and prayed tests would pass. They did and the functionality worked locally, so I figured I'd be nice and open a PR on that repo since it's basically never gotten any love. That's it.
We can see where I used that code out in the open also: https://github.com/jaredallard/binhost/blob/main/go.mod#L5

@jaredallard

I always set BINPKG_COMPRESS
to xz (which makes the inner archives of a gpkg use xz) because xz has the best compression ratio

Why not to use zstd? The later one has compression ratio similar to xz, but blazing fast decompression speed.

@maratik123
Why not to use zstd? The later one has compression ratio similar to xz, but blazing fast decompression speed.

Going forward I will now 😄 But, to be honest, I just haven't kept up with the state of the world there.

well that was some really unfortunate timing...

I get a huge kick out of updating things

Perhaps this event will get people to chill to that attitude.

Closing this for... obvious reasons 😄

I'm still baffled by how github deemed it appropriate to just hide all code and all history of this from problic eye in reponse.

None of the backdoor files (build-to-host.m4, bad-3-corrupt_lzma2.xz and good-large_compressed.lzma) are present in this repo or PR though. So let's not jump to conclusions here.

even if this PR is perfectly fine, it helps to build a "web of trust" to xz-5.6. "See, Debian guys, everyone is upgrading to xz-5.6 now, why you are slugs?"

Why not to use zstd? The later one has compression ratio similar to xz, but blazing fast decompression speed.

afaik, lzma (xz) has the same compression ratio as zstd on text files, but ~10% better on many binary files. try e.g. a large executable or a database file, use the same dictionary size and choose maximum compression

@AUTOMATIC1111 I think you assume more than there is.
They mention the breach of their terms, which mention malware as forbidden content. Since both maintainers were suspended by GitHub, they are probably just minimizing the damage and chose the easiest solution for the moment.
We'll have to wait until there is news from GitHub regarding the incident.

I'm still baffled by how github deemed it appropriate to just hide all code and all history of this from public eye in reponse.

Obviously the alphabet boys got involved

We'll just have to wait until the complicit party clarifies that it's not complicit in the cover up.

I'm still baffled by how github deemed it appropriate to just hide all code and all history of this from public eye in reponse.

its to prevent any inadvertent further deployment

Probably they do not have something more fine-grained. :/
A good solution for the future would be to have a way for their staff to mark a repository as "contains compromised code", which would then add a big disclaimer when viewing it via web, disable unauthenticated git clones, and for authenticated clones require acknowledging (via web) that you really do want to clone a repository containing malicious code.

Probably they do not have something more fine-grained. :/
A good solution for the future would be to have a way for their staff to mark a repository as "contains compromised code", which would then add a big disclaimer when viewing it via web, disable unauthenticated git clones, and for authenticated clones require acknowledging (via web) that you really do want to clone a repository containing malicious code.

I support this idea. GitHub, take notes!

its to prevent any inadvertent further deployment

Protecting history is one of the core ideas of github so scrubing it clean is not the way to go imo. Disabling clones is a better approach

Does anyone here have a mirror of xz that is relatively up-to-date? I'm trying to do security research(i.e. torturing myself for hours by going through EVERY SINGLE COMMIT by the attacker if no one else has done it) and you can't git clone from the internet archive.

Does anyone here have a mirror of xz that is relatively up-to-date?

https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://github.com/tukaani-project/xz

Does anyone here have a mirror of xz that is relatively up-to-date?

https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://github.com/tukaani-project/xz

Thanks!

Does anyone here have a mirror of xz that is relatively up-to-date? I'm trying to do security research(i.e. torturing myself for hours by going through EVERY SINGLE COMMIT by the attacker if no one else has done it) and you can't git clone from the internet archive.

Just use the official mirror: https://git.tukaani.org/?p=xz.git;a=summary

Thanks both, someone emailed me with this
https://github.com/fionn/xz-backdoored mirror(which probably will be
removed soon :().
On Sat, Mar 30, 2024 at 8:42 AM Fabian Dellwing @.***>
wrote:

Does anyone here have a mirror of xz that is relatively up-to-date? I'm
trying to do security research(i.e. torturing myself for hours by going
through EVERY SINGLE COMMIT by the attacker if no one else has done it) and
you can't git clone from the internet archive.
Just use the official mirror: https://git.tukaani.org/?p=xz.git;a=summary
—
Reply to this email directly, view it on GitHub
https://github.com/jamespfennell/xz/pull/2#issuecomment-2028074364, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ATOOUFSKEIDLRLENX3NUQ3LY22XJ5AVCNFSM6AAAAABFEK4ZLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRYGA3TIMZWGQ
.
You are receiving this because you commented.Message ID:
@.***>

Thank you for your very calm and kind response @jaredallard! I hope my comment calling this PR was suspicious wasn't too offensive. This is a crazy coincidence!
I think closing the PR was the right move. In fact, given that the xz attacker was involved in the xz repo for 2 years, I don't see any path for updating the version xz used in for this Go library at all. I am going to note on the repo readme that (a) the repo is essentially frozen and (b) the version of xz in use predates the attack so it's still potentially safe to use, depending on your risk profile. Maybe moving to zstd is the right move though.

Official announcement from XZ team is here:

https://tukaani.org/xz-backdoor/

I've sent an email to 1Password security

Maybe I should send an email to Netcraft in London that their "Security engineer I" Andy Wang is sending emails to employers making baseless claims, and to 'investigate.'

This kind of coincidence could happen to anyone who contributes to OSS.
It is a shame that some people jumped to conclusions without waiting for an explanation.
Might next times we all remember that there are different timezones around the world and that  different cultures celebrate different holidays.
Thank you very much for the calm and good sense @jamespfennell.
I hope no harm was done to @jaredallard employment relationship and that he continues contributing to OSS after this incident.

I've sent an email to 1Password security

Maybe I should send an email to Netcraft in London that their "Security engineer I" Andy Wang is sending emails to employers making baseless claims, 'possibly to shift blame' and to 'investigate if they're a state actor who have an interest in doing so.' (y'know - while we're all making baseless claims here)
Witch hunting is a shameful behavior.

FYI, informing 1Password about a possible account being compromised is the correct thing to do.
While it was wrong in this case, and it was just a coincidence. The report would, in the case of the account being overtaken a faster response both from Jared and from 1Password, allowing them to limit the damage done to both the company and the person itself. Of course in this case it was not necessary as it was simply a coincidence but if my account was compromised I’d prefer to have a warning as soon as possible (that my account was presenting suspicious behaviour)

CIA agent spotted

I've sent an email to 1Password security

Maybe I should send an email to Netcraft in London that their "Security engineer I" Andy Wang  is sending emails to employers making baseless claims, 'possibly to shift blame' and to 'investigate if they're a state actor who have an interest in doing so.' (y'know - while we're all making baseless claims here)
Witch hunting is a shameful behavior.

The email to 1Password was a security behavior. An email such as the one you're describing would be harassment/retaliation/any given number of things, and could potentially make you liable for any damages that happen next.

why don't we all just relax with the emailing of employers

Also the attacker included in the 5.6.0 release the support for the long-awaited multi-threading decompression making it very attractive to upgrade to...
It was probably a tactic to give a reason to upgrade. It's not always a fault for those who did or tried to do.

I've sent an email to 1Password security

Maybe I should send an email to Netcraft in London that their "Security engineer I" Andy Wang is sending emails to employers making baseless claims, 'possibly to shift blame' and to 'investigate if they're a state actor who have an interest in doing so.' (y'know - while we're all making baseless claims here)
Witch hunting is a shameful behavior.

???
so you want a hacker hacked 1pass then notify them?


Issues with Bootstraped pages

Bootstrap buttons don't seem to change their colour smoothly when active/inactive - is JS gutted out of your Bootstrap version?
Including a feature-img seems to break formatting badly. That's how my page looks with without an image:

and that's what it becomes when I add the image - notice it becomes much wider.

Now, I don't know how correct this is, but I managed to fix this by enclosing the Bootstraped part in post-content div instead of including it conditionally for page description only.
For the record, I want to use Bootstrap so I can use its buttons and perhaps collapsible list inside one of my pages. Is there a nicer way of doing it than using a bootstrap layout or are things I observed just "normal" issues? I noticed Bootstraped divs are quite a bit narrower, so that introduces some degree of incosistency between pages.
EDIT:
Apparently also Bootstrap theme colours are not in line with Type on Strap theme colours - but that should also been an easy fix.

I primarily want to use premade buttons from Bootstrap, as shown on the screenshot - but I may also need collapsible lists.
I realize implementing both manually should not take too much time, but I wanted to avoid spending time on developing something I am not confident with (web dev is not my cup of tea), especially when a ready solution is available.
Having bootstrap on just one page is kind of a point of bootstrap layout, I guess? In which case it's fine as-is (minus issues coming from it).

Ok I will see what's up make some tests and see how I can improve that bootstrap layout 😉

Cool, thanks for a timely response!
Perhaps you are right about making this an include instead - so bootstrap
could be used on any kind of layouts - posts, pages... Just indicate the
fact you want to use it by including it. Isolating it like you do now would
then make even more sense.
Also could solve formatting issues by not making any formatting changes in
the first place - as current Bootstrap layout has a fair share of custom
formatting shenanigans.

Hi!
So I changed the bootstrap page adding the bootstrap javascript import and using the same post-content for the formatting. Does it match your needs?

Looks like that matches my changes - I'll merge and see how it looks!
Thanks! Will update the ticket when I know the results.

Looks good! I noticed in Console log Bootstrap was complaining about jQuery not being included, so I also added a reference to jQuery 2.2.4 (as Bootstrap 3 doesn't seem to support jQuery 3.x).
Seems to be all good now!

One more question - do you have a config file you used to generate your custom Bootstrap CSS? I'd like to make a few other changes to colour schemes and regenerating css from a config file looks like the way.

Hi,
Ok I will add the JQuery 2.2.4 to the layout import.
For the bootstrap I will create a gukp task to do it more automatically.
In the meanwhile here is the website I followed to do it:
formden.com/blog/isolate-bootstrap

Could also migrate to Bootstrap 4, it's finally out of beta =)

Yep migrating to Bootstrap 4 would be another task.
I have added a couple files (less file, plus gulp tasks) in order to do the preprocessing of the bootstrap css.
Use npm install to install it (you might want to install gulp globally with npm install -g gulp)then run:
gulp isolate-bootstrap-css

It will compile the css using the bootstrap.css in assets/css/vendor/ into bootstrap-iso.css which will then be minified into bootstrap-iso.min.css. You can create a bootrstrap-theme.css file and uncomment this part in the less file to have your custom theme isolated as well.

All css related to body and html from bootstrap is vented out

You should be good with that ;)

Cool! So I take your bootstrap.css is fully stock, so it's possible to replace it with a custom one generated from Bootstrap website? Since that seems to be the best way to swap colour palettes.

Well yeah the bootstrap.css is the generic one.
But you could replace it with your customized version of bootstrap.css ;)


Streamline ss proced

What issue(s) does this PR address? Describe and add issue numbers, if applicable.

[ ] fixes issue #259.  Thanks for having this handy template ready and waiting for me.  :)

What tests have been done? Upload any model input files created for testing in a zip file, if possible.
working with hake_2021 input files that were saving report file for each mceval.
problem was the result of an interation between:  use of empirical wtatage, doing report.sso for each mceval, and changes in wtatage storage initiated during development of 3.30.19.
What tests/review still need to be done? Who can do it, and by when is it needed (ideally)?
@kellijohnson-NOAA  should take a look
Check which is true. This PR requires:
this is internal calculation only.  No other changes needed

[ ] Changes in r4ss
[ ] Changes to SS3 manual
[ ] Changes to SSI (the SS3 GUI)

Describe any changes in r4ss/SS3 manual/SSI that are needed (if checked):
none

Compared derived_posteriors.sso from 20 samples when extra reporting was turned off (i.e., starter file MCMC output = 1) using commit a0f982d and the results from an exe from this pull request. Results match for both MCMC output = 1 or 2. So success in my book. Thank you.

thanks Kelli for confirmation


⚠ Mitsubishi has degraded performance

In 5de1c14, Mitsubishi (https://mitsubishimotorsid-mobileapp.com/app/login) experienced degraded performance:

HTTP code: 200
Response time: 17671 ms

Resolved: Mitsubishi performance has improved in da343ae after .


Implement constructions counter test

A new test should run all (even disabled) and print statistics for the parent directories

Implemented a slightly different counter in #299


Ignored includes: show a query that uses blog.Posts

The example currently only shows that the blog posts are ignored because of an optimisation (Posts aren't used in the anonymous type)
I think this should section should be extended to show that even when they are used, it still won't work, e.g. :
.Select(blog => new
{
    Id = blog.BlogId,
    Url = blog.Url,
    HighlyRatedPosts = blog.Posts.Where(post => post.Rating > 3)
})

HighlyRatedPosts will be evaluated lazily in this case
Here's one issue I think that is talking about this: https://github.com/aspnet/EntityFrameworkCore/issues/4641

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: bbd36f35-e257-d0ed-8f28-f539ddcb71ec
Version Independent ID: 093903d5-f7c7-5a78-c0e5-0e2662dcedef
Content: Loading Related Data - EF Core
Content Source: entity-framework/core/querying/related-data.md
Product: entity-framework
GitHub Login: @rowanmiller
Microsoft Alias: divega

@adamburgess This:
.Select(blog => new
{
    Id = blog.BlogId,
    Url = blog.Url,
    HighlyRatedPosts = blog.Posts.Where(post => post.Rating > 3)
})

doesn't require an Include call. Projection of navigation properties is independent of Include.


Modal closing when selecting datepicker

Bug Report
I am using react-datepicker for the following test.
When selecting a date in the datepicker inside a modal, the modal also close together with the datepicker. It's working fine with react-bootstrap and react-material modal, so I assume the problem is with semantic ui modal.
Steps

Create a modal using semantic ui.
Add datepicker inside modal.
Select the date and when you click the date, it will close the datepicker as well as the modal.

Please see codesandbox below to demonstrate the issue.
Expected Result
When clicking the datepicker it should only close the datepicker.
Actual Result
When clicking the datepicker it close the datepicker as well as the modal.
Version
React semantic ui: 0.81.1
react-datepicker: 1.5.0
Testcase
https://codesandbox.io/s/y7q96n58q9

Hey, I'm using the same setup. This happened to me as well, when the react-datepicker was overlapping the modal's edge and I clicked the date which was positioned out of the modal.. Technically, I clicked out of the modal -> modal closes
Solved temporarily with not passing onClose prop and handling close myself

@honzajerabek thank you so much for the info, do you have any example on your workaround.
I tried passing onClose callback but the event that get passed to that callback function is MouseEvent and the data is the modal itself.

This only happening when using the property trigger if you use the property open of the modal it does not happen.

It's happening when I use open as well. Even when the I handle the close function manually, it's still happening.
Please see the following example:
https://codesandbox.io/s/z6xoo25p3p

I added showModal to handleChangeDate so that it closes when the user changes the date:
https://codesandbox.io/s/q49pz8y46

It closes because your event handleChangeDate changes showModal to false.
handleChangeDate = (date) => {
    this.setState({
      date,
      showModal: false
    });
  };

Ok. I think I understand now. Thank you!
On Fri, Jul 6, 2018 at 7:20 AM, Herbert Pimentel<EMAIL_ADDRESS>wrote:

It closes because your event handleChangeDate changes showModal to false.
handleChangeDate = (date) => {
this.setState({
date,
showModal: false
});
};
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Semantic-Org/Semantic-UI-React/issues/2945#issuecomment-403006023,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ae11GYAwWAkCe-Z9V4aKS9xdu6QkW2F6ks5uD0gXgaJpZM4U1j64
.

This issue has been fixed with the release of 0.82.1, the fix is on #3015. So I think we can close this ticket.
Thanks @layershifter .


Add OCI Generative AI new model support

[x] PR title:
community: Add OCI Generative AI new model support

[x] PR message:

Description: adding support for new models offered by OCI Generative AI services. This is a moderate update of our initial integration PR 16548 and includes a new integration for our chat models under /langchain_community/chat_models/oci_generative_ai.py
Issue: NA
Dependencies: No new Dependencies, just latest version of our OCI sdk
Twitter handle: NA

[x] Add tests and docs:

we have updated our unit tests
we have updated our documentation including a new ipynb for our new chat integration

[x] Lint and test:
make format, make lint, and make test run successfully

Hi @baskaryan, we have PRed a moderate update to our Oracle OCI Gen AI integration that passes all the tests but seem stuck with Vercel (deployment) which we don't have access to.  Is there anything we can or need to do the push forward the process?
Many thanks
Rave

Hi @baskaryan, we have PRed a moderate update to our Oracle OCI Gen AI integration that passes all the tests but seem stuck with Vercel (deployment) which we don't have access to. Is there anything we can or need to do the push forward the process? Many thanks Rave

it found broken links:
Exhaustive list of all broken links found:

On source page path = /v0.2/docs/integrations/providers/oci/:
-> linking to /v0.2/docs/integrations/llms/oci_generative_ai.ipynb/
-> linking to /v0.2/docs/integrations/chat/oci_generative_ai.ipynb/
-> linking to /v0.2/docs/integrations/text_embedding/oci_generative_ai.ipynb/

i think you dont want to include the .ipynb in the url (since when we build the docs, those will become html

thank you very much @hwchase17 :-)
It has now passed all checks.
Kind regards
Rave

@hwchase17 could you please merge this PR? Many customers are awaiting for this. Thanks.

Hi @hwchase17, @ccurme, @baskaryan, do you have an estimate on when this PR will be merged?

@ccurme, thanks very much for the quick response.


0.10.7

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

For reference: https://github.com/conda-forge/openff-toolkit-feedstock/blob/d627bc31b72e0ad50c50404acb0f8526905bba56/recipe/meta.yaml


Mine current subtitle shortcut is only copying current subtitle

Before submitting an issue check out the common issues section of the README:
https://github.com/killergerbah/asbplayer?tab=readme-ov-file#common-issues
What is the issue and how what do you do to make it happen
When I do the shortcut hotkey for mining the current subtitle, it just copies it to the clipboard. I have it set to export to Anki. Clicking the mine button on the overlay or sidebar works as expected.
What browser?
Brave 1.71.114
Is it happening with local video or streaming video?
Streaming (all platforms)
If the issue is happening with streaming video, what version of the extension are you using?
v1.5.0
If the issue is happening with streaming video, on what website(s) is the issue happening?
Prime Video, Netflix, YouTube.

Yes, as I mentioned in the original post, that shortcut works fine.
However, I’m looking for a one-click shortcut that will just mine the
current subtitle without opening any dialog boxes. Since there is no way to
do that, I’m currently having to use an external program to map a button
click to a controller with a precisely placed cursor so I can click through
the dialog box. Kind of a pain when it seems like there should be a
shortcut to just mine when you can do it by clicking the overlay or the
sidebar. Hope that’s clear, thanks!
On Fri, Oct 25, 2024 at 3:44 PM Raphael-Joel Lim @.***>
wrote:

Which shortcut are you using? You need to use the "mine current subtitle
and open Anki dialog" shortcut.
—
Reply to this email directly, view it on GitHub
https://github.com/killergerbah/asbplayer/issues/548#issuecomment-2437410253,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BI5UJKALKXG7VWVLJIB24NDZ5IKXNAVCNFSM6AAAAABQJPCN52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZXGQYTAMRVGM
.
You are receiving this because you authored the thread.Message ID:
@.***>


nbAgg notebook/matplotlib background ginga window communication

The nbAgg notebook backend lets you embed the ginga/mpl window in the notebook but the calls to the window need to change for valid communication

added with ginganb merge 632f01f4a0d86b56868fcd4f4126d4eeafd59a09