Assign existing IP Address to Device Interface

Issue type
[x] Feature request
[ ] Bug report
[ ] Documentation

Environment

Python version:  Python 3.4.5
NetBox version:  v2.2-beta1

Description
From the device page, there's only the option to add a new IP address. From the IP address edit page, the "Interface Assignment" section is hidden. There is actually a workaround if you manually modify the IP address edit URL to include ?interface=x. If it isn't desirable to have the Interface Assignment section show up on every IP Address edit screen, it'd be nice to have a button on the Device page next to the current "New IP" one.

Related: #786, #1001, group thread
That thread says:

As interfaces can now be assigned to both devices and virtual machines, it becomes very difficult to specify interfaces without additional context. For instance, when creating an IP, you can assign it to an interface by searching for a device, by selecting a device (from a series of dropdowns), by searching for a virtual machine, or by selecting a virtual machine. It becomes very tedious and confusing to include all of these widgets in a single form.

Another option would be to allow linking an existing IP address to an interface, rather than vice versa.  It might work like this:

When you click "Add address to interface" (on either a Device or VM) you get the same page as now
When you click Add, then the system searches for any existing address(es) with the same Address and VRF.  If none are found, it just creates a new one as now, linked to this interface.
However, if one or more matching addresses are found, then it refreshes the page including a list of matches in a table, and offering the option to:

click on one of the existing addresses to link it to the this interface [^1]
create a new address anyway (this is only offered if the VRF allows duplicate addresses)

Alternate flow:

When you click "Add address to interface", you get a short form with Address, VRF and Search buttons only
After clicking Search, you get a new form:

Address and VRF displayed at top (non-editable)
Any existing matching IP addresses displayed in a table, with "Link to this address" button for each
Remaining fields for the Add Address page (Status, Role, Description, Tenancy... Create button). This section displayed only if the search returned no results, or the VRF allows duplicated IPs

[^1] If the address is already linked to another interface this should be indicated in the results table, but you can still take it over.

Just to be clear: the UI no longer appears to offer any way to assign an existing IP address object to an interface.
You have to delete the address, and recreate it when you add to an interface.  This is inconvenient because it means all the information relating to that address has to be re-entered (Status, Role, Description, Tenancy etc); furthermore, the Address changes its API ID, and the Django history of changes to that object is lost.
A specific use case is when migrating from a flat IPAM spreadsheet to Netbox.  Starting from a flat model you likely will import all the IP addresses first, and then later decide to create devices/vms/interfaces to attach them to.

We're currently experiencing the use case @candlerb mentioned, using ?interface=X is a workaround, but it would be nice to have a way to do this without needing to resort manipulating the URL.
It would be also a nice workflow being able to select a free IP in the IPAM and then assing it to an interface when creating the IP address.

Additionally it is no longer possible to move an ip-address from one device to another without deleting and re-adding the ip-address.
IMHO this is not an enhancement but an regression, as functionality is lost

Both linked cases are closed. One should stay open until resolution correct?

I think this is also a bug and not a feature request.

Could we get an update as we are unable to assign a device and interface when editing or adding an IP Address.

Any update as this is a critical issue.

I'll chime in and add that this really is a critical feature.  I completely sympathize about the potential for an excessively cluttered dialog in attempting to associated interface/VM-interface back and forth to an IP.  But, I would be willing to take slight clutter to (re)gain this feature.
The ability to cleanly find, (pre)create and associate IPs-to-interfaces and interfaces-to-IPs is well worth the complication IMHO.  (I can give gory details on our live use cases if it's interesting)
@candlerb's ideas are minimal and the first is transparent, which is great.  Here's another that involves user input but also provides good feedback to the user when creating or reassigning IPs

Add a prefix selector dropdown on the add-ip-address form, constrained to the prefixes associated with the device's site, perhaps grouped by VRF.  This selector can be optional, and the IP field can still accept freeform IP/mask input.  This has a side effect of allowing IP-in-prefix validation, at least on the user side, if a prefix is selected.
If a prefix is selected, the Address input field could have a widget akin to https://github.com/djk2/django-popup-view-field (which can render existing views and could be useful elsewhere as well), which would allow for selecting an existing IP.  Constraining this to only when a prefix is selected dodges around an excessively large contents inside the widget.  It also could give an opportunity for users to see free IPs inside a prefix, for selection rather than manual entry.

Since it's comparatively easy to reassign or even recreate IPs via the API, this mostly distills down to a UI/UX issue, IMHO.  Honestly, not my strong suit but I do know the current UX is is very difficult for my engineers ;)
I'd be happy to help work on this.

Pardon my naïveté, but wouldn't the simplest solution be to redefine the VMs as a subcategory of devices, (say, by adding a column VM, which defaults to 'no', in the devices table) which would allow to populate the form's drop-down with only devices?

Devices and VMs already share the same Interface object.
The issue being discussed here is: (1) being able to assign an existing IP address to an interface; and (2) being able to move an existing IP address from one interface to another interface on a different device or VM.
Certainly, if you approach this from the IP Address side, you'd have to identify the interface to attach it to.  This could be done simply by a search on the name, showing all Devices and VMs that the search matches.  That's more convenient anyway than drilling down via Site -> Rack -> Device, or Cluster -> VM.
If you've already navigated to a particular Device->Interface or VM->Interface, then you just want to search for a particular IP address to attach to it.

Adding my +1 to this issue. Was about to report this myself.
Before there was VM support, we had added "FQDN" and "Port Translation" custom fields to our IP objects. We also resorted to putting machine names in the Description so we could find their IPs.
When I started trying to connect all of the pre-existing IPs with these VMs, I discovered the fact that assignment of the IP is impossible from either end. Can't connect it by editing the IP, or can't connect it when creating the interface on the VM and trying to assign the IP.
I can see how this interaction is easily overlooked, but it has halted documentation. Without a way to at least bulk-import these interface creation+assignments or a way to link these objects, it's too tedious to delete and recreate IPs.

Аnd me, you can also add to this issue.
Created in advance a lot of the right ip addresses and then was unpleasant surprised trying to assign them devices and ports!

I am also affected by this. We have first migrated all our IPs into Netbox and then, as we add devices, we assign IPs to various interfaces. This is no longer possible since the last update.
I don't really understand why #1639 is marked as a duplicate of this and closed. It seems to me it's a severe loss of functionality. This assigning an IP to a device interface is supposed to be done now by editing the device, then this issue should be a bug since that's not possible.

Until they fix this, the workaround is to append '?interface=###' to the URL where ### is the interface number referencing the device interface you need to connect. The options will appear.
This is still incredibly tedious though. I might just create a script button that hooks into the browser or a hack-job extension to do this in the meantime.

Just to be clear, you add this to the URL when you are editing the IP address. Example:

Navigate to /ipam/ip-addresses/9/edit/
Change this to /ipam/ip-addresses/9/edit/?interface=33 in the URL bar
Hit Enter to redraw the page.  The correct interface should now be shown.
Click Save

And to find it's interface 33, you first need to navigate to the device or VM in question, and click the edit button (pencil) next to the interface.

Yes, I am familiar with the workaround and I am using it. It works but it's extremely inconvenient, as already mentioned. I hope this will be solved soon. I am just very surprised this is treated as a feature request and not a bug.

Can we change this to a bug as this was available in a previous version?

We only just started using netbox, so I didn't even realize when reporting this that it was a regression, which it definitely is if this was possible in previous versions. This issue is the reason we've had to put our implementation on hold.

Yup, It has only been removed since the VM support was added.

Sweet! Testing now. Thank you @jeremystretch!

Works for me. Cheers!

Awesome, thanks!

I upgraded to 2.2.5 and when I edit an IP address that is not linked to an interface it still does not provide the option to select a device/interface unless I use the work around of appending ?interface= to the URL?

@insanesplash it is now another tab. You will see the "add an IP address" vs find one at the top of the page after you click the green plus

That is: you can't do it directly from the IP address.  Instead, you have to navigate to the device or VM where you want to attach the IP, then click the green plus next to the interface you want to attach it to, then use the tab as @DirtyCajunRice says.

Still minor issue but created new issue #1718


Kourend library enhancements

Always:
Current requested book has the tile border changed to green color
Dark manuscript added to the UI panel
Dark manuscript location parsing added when talking to Biblia
Some null pointer checks added to original plugin
Optional:
Vilramore Envoy tile marker no longer shown as it is never requested
Dark manuscript locations no longer shown unless inside the room confirmed by Biblia
Left click "help" menu swap from "talk-to" added
TODO:
Hide currently owned books in the UI Panel
Add all manuscript locations to panel instead of "Unknown"?
Store manuscript locations differently?
Current bugs:
None Known

I believe @Hydrox6 has been looking at improving this plugin recently, can you review this?

I'll remove the Biblia tracker - I didn't know the NPC indicator plugin existed.

@Hydrox6 how much of this do you want now that 10315 was merged?

It's mainly just the Manuscript and Biblia stuff, though it needed work before. I'll have a look when I get back in a few hours and check the changes

Closing this because superseded by #10315


As a developer, I want to develop API so that we can interface on-demand SDS

initial sds-api is complete


RFC - accept xml content

hi @eriklupander
for now, gotling only support accept: json, it'd be good if can support xml as well.
i saw there is golang xmlpath implement the xpath spec.
thanks

Sounds good, xmlpath (or perhaps gpath if there is a golang implementation) should be supported.

I have pushed a first attempt at using xmlpath. Seems to work but code needs to be cleaned up, unit-tested etc.

it'd better to mention in README that go-xmlpath does not support xml namespace yet https://github.com/go-xmlpath/xmlpath/pull/8


Demonstrate binary operations

These #124 , #161 PRs say that not everyone is sufficiently familiar with binary operations and confuses them with the AND operation.
Perhaps it will be better understood that these are binary operations and the advantages of binary operations will be more obvious.

Thank you :+1:


HIVE-25179: Support all partition transforms for Iceberg in create table

What changes were proposed in this pull request?
Enhance table create syntax with support to partition transforms:
CREATE TABLE ... PARTITIONED BY SPEC( year_field year, month_field month, day_field day, hour_field hour, truncate_field truncate[3], bucket_field bucket[5], identity_field identity ) STORED BY ICEBERG;

Why are the changes needed?
Previously we had support of partition transforms through TBLPROPERTIES, but that syntax is a bit cumbersome. For instance:
CREATE EXTERNAL TABLE (id BIGINT, part_field DATE) default.part_test STORED BY 'org.apache.iceberg.mr.hive.HiveIcebergStorageHandler' TBLPROPERTIES ('iceberg.mr.table.partition.spec'='{"spec-id":0,"fields":[{"name":"part_field_year","transform":"year","source-id":2,"field-id":1000}]}', 'write.format.default'='AVRO', 'iceberg.catalog'='default_iceberg')

Does this PR introduce any user-facing change?

How was this patch tested?
Unit test, manual test

@jcamachor @zabetak @marton-bod @pvary @szlta Could you please review this PR? Thanks

Looks great @lcspinter! Just a few questions


"tags include" shall be full word matching

When we "tag" something, we usually mean the tag is a non-separable entity.
Thus, one file with tag “abcdef” shall not appear in tag search of "abc" or "cde".
When I import hundreds of files into VHA, this problem makes the tag searching unusable.
I suggest "tags include" shall enforce full word matching, if partial word matching shall stay as a feature, it could be a standalone option, or just include it in the fuzzy search.

Thank you for the Iussue
The downside of implementing what you recommend is that some tags might be as long as a full actor's name (e.g. "Tom Cruise") in which case the user would have to type in the whole without any spelling mistakes.
Videos with each tag (labeled at Tag search - 7th on the list of "Search filters" in the settings menu, "Search settings" - 1st tab) has auto-complete. When you start tying the tag and it shows the full tag name, you can press the Tab key on the keyboard to perform the search!
Another way to achieve what you'd like is to simply open the Tag tray (on the bottom) and click on the tag you have in mind.
Please let me know your thoughts 🙂

Thank you for the Iussue
The downside of implementing what you recommend is that some tags might be as long as a full actor's name (e.g. "Tom Cruise") in which case the user would have to type in the whole without any spelling mistakes.
Videos with each tag (labeled at Tag search - 7th on the list of "Search filters" in the settings menu, "Search settings" - 1st tab) has auto-complete. When you start tying the tag and it shows the full tag name, you can press the Tab key on the keyboard to perform the search!
Another way to achieve what you'd like is to simply open the Tag tray (on the bottom) and click on the tag you have in mind.
Please let me know your thoughts 🙂


Intermittent GlobeSurfaceTile test failures on CI

@shehzan10 do you want to look at this at the bug bash?
These tests fail Intermittently.  Perhaps there is a way to simplify them and make them more consistent.
  Scene/GlobeSurfaceTile
    processStateMachine
      ✗ upsampled terrainData is copied to the tile once it is available
	Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL.
      ✗ loaded terrain data replaces upsampled terrain data
	Failed: promise rejected: TypeError: Cannot read property 'state' of undefined
	    at Specs/customizeJasmine.js:79:26
	    at Object.then (Source/ThirdParty/when.js:217:33)
	    at Source/ThirdParty/when.js:297:13
	    at processQueue (Source/ThirdParty/when.js:647:4)

Sure.

@shehzan10 did you get a chance to look into this yet? This test failure keeps making greenkeeper throw up errors

I did look into it around the February bug bash, but it was incredibly hard to reproduce as it was only happening intermittently. I don't really have any update on why this is happening because of that.

Does this test use external data? (If so that could certainly be part of the problem).
We should either fix this ASAP (preferred) or exclude the test in master (via xit) because it's making our unit tests too unstable.

I agree with @mramato.  Given that we are focused elsewhere, perhaps just xit for now.

Ignored for now in #5085.

We are still receiving frequent travis failures because of the below two related tests.  I would recommend we xit these as well, but there's a large problem here that we really need to look into sooner rather than later.
1) loaded terrain replacing upsampled terrain triggers re-upsampling and re-loading of children
     Scene/GlobeSurfaceTile processStateMachine
2) improved upsampled terrain triggers re-upsampling of children
     Scene/GlobeSurfaceTile processStateMachine

Agreed.  @rahwang do you want to make this small change: https://github.com/AnalyticalGraphicsInc/cesium/issues/4968#issuecomment-287766749

Sure thing!

Those other two tests are now ignored #5135

The problematic tests have been removed at this point.


Add hardhat-abi-exporter

I think that we should create different pages for zksync-specifc plugins and plugins that work out of the box like this one. Just because if we keep adding more plugins here it'll be a super long list and I don't think mixing them would be a good idea.
What do you think @krofax @githubdoramon ?

I think that we should create different pages for zksync-specifc plugins and plugins that work out of the box like this one. Just because if we keep adding more plugins here it'll be a super long list and I don't think mixing them would be a good idea. What do you think @krofax @githubdoramon ?

Agree... makes a lot of sense to have a separate section for "regular" plugins that can be used out of the box

I think that we should create different pages for zksync-specifc plugins and plugins that work out of the box like this one. Just because if we keep adding more plugins here it'll be a super long list and I don't think mixing them would be a good idea. What do you think @krofax @githubdoramon ?

Totally agree too, it's almost already looking long.

we should create a page for plugins that work out-of-the-box and just link to their official docs.


Proposal: Remove Bot and request from Tree view

Like in the unroll view, we could hide the requests to unroll and the bots answer in the response

The tree view should show all replies imo.


Breakpoints context menu

Testing #16013
IMHO:

context menu actions should be grouped in two sections: ones that contains actions applying to the current breakpoint and one that contains "global" actions
it would be nice if the label "Enable/Disable breakpoint" would reflect the state of the current breakpoint
it would be nice if some of the duplicated "global" actions could be removed.

I see there is now a lot less entries in the menu:

For example, no more way of adding a "Function breakpoint".
@isidorn please clarify what to verify here.

@bpasero please verify the context menu makes sense and that there is no dupication between actions in the breakpoint title and the context menu. That the actions are nicely grouped together.
That the enable / disable label gets updated.
Bascially what alex critized in the original issue

Ok I am not sure what kind of rule you are following here, it seems you removed some of the commands that exist in the header (e.g. Disable All Breakpoints and Add Function Breakpoint) but you still left in Remove All Breakpoints.
Maybe we should just go with what dev tools do:

Anyhow, I give you the verified for cleaning up the menu.

No we are way cooooooler


Pass route action's arguments to navigateAction's done callback

It would be useful to propagate the route action's arguments through to navigateAction's done callback.
============
routes.js
============

module.exports = {
  thing: {
    path: '/thing',
    method: 'post',
    action: function(context, payload, done) {
      var res = payload.getIn(['navigate', 'body', 'foo']); // res === 'bar'
      done(null, res);
    }
  }
};

============
postThing.js
============

var payload = {
  url: '/thing',
  method: 'POST',
  body: {
    foo: 'bar'
  }
};

context.executeAction(navigateAction, payload, function(err, res) {
  if (err) {
    // throw err
  } else {
    // do something with `res`
  }
});

Currently, res is undefined in the above snippet

I wouldn't recommend using actions to send data back up the chain. Actions have callbacks only so that we know when they have completed, not to pass data around between them. The stores should be the source of truth for any data. In the parent, you could call context.getStore(RouteStore).getCurrentRoute() to get access to that information.

CLA is valid!

The documentation for FluxibleContext states that the callback for an executeAction call may receive error and result parameters. If this is true of the FluxibleContext, is it not also true for the Action Context? Or have I misunderstood the intention?
http://fluxible.io/api/fluxible-context.html#executeactionaction-payload-callback

You're right it does mention that. We've found that this pattern has caused inconsistency as far as what the source of truth is. We will probably remove that from the documentation, although we will not remove the capability to send data back.
With that said, I don't think we should add the pattern to fluxible-router to encourage people to use it.

I see, thanks for clarifying, I agree now that Actions should be fire and forget.
We have a small number of generic Action Creators that make calls to an API using Fetchr. These are called from our route handlers. When calling a generic Action Creator, the route handler passes in extra functionality using the done callback, which does things with the response (e.g. dispatch Actions specific to the intention of the API call).
In the cold light of day, it is clear that this is an antipattern and, having coded ourselves into a corner, we were using callbacks as an escape hatch. We'll probably ditch the generic Action Creators for making Fetchr calls, and instead encapsulate the Fetchr call and response handling in the route handlers.
Cheers for your explanations.


Describe the feature you want to add
Support Quart unit (for water)
Describe your proposed solution
No response
Describe alternatives you've considered, if relevant
No response
Additional context
References:

https://www.inchcalculator.com/convert/volume/

@sadrasabouri Please take care of this when you have some free time. 💯


CHIP-0032: Block NoSSD

This is a first cut at a CHIP to block NoSSD from continuing to damper NC. This was a quick cut, and the implementation seems straightforward, so I felt it was better to publish quickly and get feedback even prior to having a complete implementation.

Here are a few reasons I think this is a terrible idea:

Censorship is one of the core things of what blockchains aim to solve. Attempting to "improve censorship resistance" through censorship is comically hypocritical.
"We are not setting a precedent that any developer can be censored." Yes you are because you are subjectively defining what is considered to "harm Chia". I would argue potentially losing 11 EiBe of netspace harms chia more than a lower NC.
I could also argue the even the proposal of such a CHIP reflects negatively on the ethos of the chain and harms Chia more than NC=6.
This directly hurts farmers that made rational economic choices to maximize farming rewards by forcing them to replot (maybe twice if new plot format comes later).
This is a bandaid solution (which I think is not a soft fork) that would require at least one more bandaid solution in your scenario of NoSSD continuing their model after a new plot format. We'd have to successfully fork in their new address at that time or more likely is they will rotate a number of reward addresses to sybil against further censorship after a replot.
As quoted, NoSSD is not violating any consensus rule. Would you also opt to censor a gigawhale farmer with a significant amount of netspace as well? Would you add other non official pooling protocol pool to this list?
Do we know for sure NoSSD is not adopting CHIP-22? Have they been given enough time to build an implementation (that would likely require their farmers to replot btw) that they are comfortable will secure their own dev fee?
"We’ve identified a bug in consensus which allows NoSSD to rapidly centralize the network" what bug are you referring to?
NoSSD is already expected to have their share of netspace drop due to GH3 and DrPlotter's better efficiency. Not to mention the upcoming plot filter reduction that may see farmers move off of compression, and even the new plot format discussions that would also address the NC indirectly.

This is very well written and I completely understand your rationale
I just think it is the wrong direction because I have never seen censorship advance human civilization
like, ever
And for that reason I am out

Disappointing proposal. NoSSD in current format hurts NC but censorship hurts Chia more.

I'm not a fan of NoSSD because of their past behavior and the fact that they kept their tech closed source, but censorship is not the answer.
Better technology however is in the end, always the answer. NoSSD won the race because it had better tech, and farmers trying to maximize profits went to it. It will eventually fail to new better tech. GH and DrPlotter are better techs, so it's up to the farmers to switch.
Trying to pin the current low NC on NoSSD is if not malicious, at least misleading.
We want a higher NC, but the way to achieve it is through better technology and farmer adoption.
I'm disappointed in this CHIP proposal.

It seems you haven't examined too closely how NoSSD works and what they have done to obfuscate their key to prevent CNI from doing exactly what you propose here:

If you try to look at the NoSSD won blocks, you will notice that every single one uses a different pool public key. It is suspected that the plotter and farmer are using a deterministic approach to assigning unique public keys (Farmer public key and Pool public key) to every single plot to prevent anyone from blocking their farm from producing blocks. I have also theorized that this additionally prevents anyone from discovering them skimming because they could easily not report some won blocks.
NoSSD operates as a central farmer with all their customers as remote harvesters to that farmer, this is why they are bad for NC. The plotter automatically makes plots for their customers, they have effectively created one click farming. The NoSSD client just harvests the plots and sends the proofs to the central farmer, which then makes the blocks. The individual clients don't control anything about making a block.
If we were to publish a chip to block their farmer reward address, they would simply change it, because they are using plots made with farmer public key and pool public key. The reward address is controlled by the farmer making the block, not baked into the plot itself. They can literally change their address the second the commit is merged to a release with no action required by their clients.

I expect this CHIP to attract more attention than most, so I'll be a little more thorough than usual here.
@evergreendrose This comment is mostly for your benefit, but others can feel free to follow along.
This will be CHIP-0032, or CHIP-32 if you like. I have made a few edits to the formatting to make the markdown happy, but otherwise I have not edited the content.
I have taken the liberty to assign myself as the editor for this CHIP. This means that I will be a neutral arbiter for this CHIP as it goes through the usual process. I realize I have already given my opinion on X, but I will refrain from further doing so. Dylan -- if you feel that this disqualifies me from being an editor, or if you feel that I'm not faithfully acting as a neutral arbiter, let me know and a new editor will take over.
This CHIP is now a Draft. At a minimum, in order for it to be moved to Review, it will need a reference implementation and some test cases. I have also put together a list of additional items that should be clarified:

In certain sections, you state that this CHIP will require a soft fork, and in others you state it will require a hard fork. Please clarify which one it is. Preferably, you can add a few lines to the Backward Compatibility section with your rational for the fork type.
Do you know the technical details of how NoSSD's farming address is derived? @scrutinously is suggesting that they could circumvent this proposal with ease. Can you supply us with a contradictory analysis?
Can you give some analysis for your three-month proposed timeline? Would this be a sufficient amount of time for farmers to replot? (It would be good to understand how a long a whale with multiple PiB would need.) Or is this not part of your consideration?

Other questions may surface during this process as well, but this seems like a good starting point.

A few things to clarify for everyone:
At this point in the CHIP's process, it is a draft proposal. This does not mean it will be implemented. In order for that to happen, more info is needed (see my previous post), and we'll need to have general consensus from the community.
That's where you come in. Everyone should feel free to review this CHIP. Add a comment to let us know if you agree or disagree with it, and why. You can also comment in the #chips channel in our Discord. Comments act as a quasi voting system. Engagement in these two locations will be considered in how broadly this CHIP is being supported.
The timelines for finalizing CHIPs is fairly open. Once there appears to be broad consensus for this proposal, as well as a working reference implementation and test cases, we can move it into Review. Because this will require a fork (at this point it's unclear to me whether this will be a soft or hard fork) it will require a higher level of testing and scrutiny than most CHIPs. I would guess at least one month would be required in Review, but that's still a bit fuzzy. Once we have crossed the testing/review threshold, the CHIP can be moved into Last Call for two weeks, and then it will become Final. Note that even after a CHIP is Final, it's not guaranteed to be added to all clients.
The real "voting" mechanism will occur if/when this CHIP is moved into Final. At that point, if it is added to any existing clients, every Chia farmer will need to decide whether to support the CHIP by installing (or not) the software. The uptake will need to exceed 50% of netspace in order for the fork to be successful.

@nossdpool I'm pinging you as this CHIP pertains to your software. Feel free to comment as desired.

I don’t agree with this current proposal as its completely missed the step dialogue with nossd. This proposal should only be the last resort and this chip or another one should be created to get consensus first to approach nossd to change their protocol.
As I'm not technical in side things and nossd has closed sourced software from what scrutinously said regarding blocking one address it wouldn't work anyways due to “It is suspected that the plotter and farmer are using a deterministic approach to assigning unique public keys (Farmer public key and Pool public key) to every single plot to prevent anyone from blocking their farm from producing blocks. I have also theorized that this additionally prevents anyone from discovering them skimming because they could easily not report some won blocks.”.
While I agree broadly with what was mentioned by creator of the chip I believe dialogue first is paramount instead going straight to a ban.

I will add my two cents to this proposal.  So there may be a presumed underlying bias with my opinion.  But I want to say that even if I didn't have 35 PiBe of NoSSD plots right now, I would still be against this proposal because censorship would become a slippery slope.  Who gets to define what is a sufficient "problem" to block someone from the blockchain. As SlowestTimelord pointed out, an NC of 6 is likely less of a problem than being known as a blockchain that can be censored.
Second, also already pointed out, superior technology is going to be what beats NoSSD. It's analogous to freedom of speech in the USA - rather than allow the government to control speech, we have ideals that more voices with the truth will win out in the end. With this technology, the better tech will win out in the end.  We don't have to manipulate or force anything.
Finally, this proposal would wipe out 11 EiB of netspace if it was even possible. It would certainly stir up massive conflict with the mega-whales on NoSSD. All of this would be terrible for the health of the community and health of the network.
Even without my NoSSD farm, I would be against this proposal set forth in CHIP-32.

It won't work.

I am disappointed to see this proposal. Of course we want to encourage decentralization as much as possible, but the censorship approach is misguided in spirit and problematic in implementation to say the least. I hope this proposal is forcefully rejected.

Farmers are free to pick their tools: and if you'd prefer they pick different ones... then build better ones. NoSSD isn't doing anything wrong: just offering an option that many farmers are choosing for themselves to use.
I haven't had to login to github for years: but this proposal was so poorly thought out I had to go find my creds. The idea that a project that's interacting properly with the Chia community would get censored is ludicrous.

I think scrutinous made some strong points on the tech side of things why this won't work, and it seems max thinks so as well. Since this seems to be a more community oriented chip, and I feel their are repercussions in general just from the ideas mentioned in, I will still post my thoughts around it that may be more "lateral" to the actual proposal.

While NoSSD does hurt the NC of the chain, they are still operating within the bounds of consensus and have not shown in any way they are a bad actor. There are no requirements for them to "dox" themselves  given the ideals of bitcoin, ideals that chia inc has mentioned they based the chain on, and the general ideals supported by the community reflect this.

As mentioned by others, farmers running evergreen light farmer also use a centralized node that get to choose what foliage to include with the block. Going back to the ideals and bitcoin and blockchains in general, this is a permissionless
system. No one should be assumed to be a good or bad actor, this is all handled by consensus. If there was a case of block censoring  or if the community as a majority had issues with NoSsd they could choose to attempt to reject NoSsds blocks to counter it, but most would not want unless given a strong reason. Being a permissionless chain, the node that evergreen farmers use can be deemed to be just as much of a good or bad actor as NoSSDs node, without any proof to show otherwise.

If Chia Inc. were to implement any code to fork out NoSSD if even possible, it would make a strong argument that they are are centralized arbiter of the chain. The only way it could be seen otherwise would be if such a chip had near universal community support. Touching on this even more, the fact that NoSSD exists running either their own node, or a modified node leveraged for their own intent and purposes helps establish Chia the blockchain as a community driven effort  and shows that Chia Inc. does not act as a centralized entity controlling the chain.

Touching more on point 4, if Chia Inc. were to implement censorship at any point, it would be setting a non-legal, but still strongly arguable precedent that they can censor the chain. This means if there is ever a case where a government entity were to request censorship in any situation, Chia Inc could be found to be legally liable if choosing not to do so, as they would have done so before in other context and wielded such power . This is a big point being overlooked in a proposal like this. As such, implementing a chip like this would have many ramifications for both Chia Inc, and the community as a whole. For Chia Inc. it would be in the legal sense, for the community it would be a "First they came for ____ and I did not speak out." But over all in my opinion nothing to do with it would better the chain in anyway and in every case other than the NC number it harms the chain.

While I don't know your intents for this chip, and don't want to make any assumptions, I think from a business standpoint even submitting such a chip looks really bad. You run a company where near all of your farmers don't run a node, NoSSD offers the same. If there was a situation where they were knocked off chain via NoSSD being blocked, the fall back would be fast farmer. While this doesn't mean evergreen would profit directly and they would have any reason to purchase from evergreen, there is a very important aspect here, that fast farmer would be a viable alternative. Fast farmer was developed IIRC via a grant from Chia Inc. Fast farmer also implements competing compression from MadMax, and as such when a farmer uses fast farmer with GigaHorse compressed plots, part of the fees go to the developer of fast farmer. While I don't know exactly how fast farmer development is tied to EverGreen or anything around the usage of the fees garnered by it use, this seems like a fairly large conflict of interests. Given what I outlined above it could be argued that the motives behind this chip could be rooted in this conflict and it could be argued that as such this chip is being used as a form of regulatory capture. I will state once again, I don't know your motives and I am not accusing you of this or think that is the reasoning for the chip, it needs to be pointed out.

As a permission-less chain no one should have to assume anyone's motives and as such I feel like such a chip, that aims to implement this through Chia Incs. own proposal process is not the place to take such actions. As outlined above, NoSSd could have their own motive, EverGreen may have their own motives, and to preemptively take actions around assumptions goes against the natural and ideals of blockchains and their community. If you or anyone else feels they should take action against NoSSD, anyone can do so right now via an edit to the open source client. People are free to take actions and vote via what they choose to validate. This would make the process of "forking" or "invaliding" not a top driven endevour. While I have stated blockchains and their community have ideals that normally don't align with censorship that everything should be permissionless and and assumptions of whether someone is good or bad should not be required, users are still capable of taking these assumptions and taking action through the weight of their own participation, but any form of it not being a community driven, decentralized effort, seems to be the wrong approach, and my IMO an improvement proposal  leveraging Chia Inc for the implementation is the wrong place for such an action. If there was actual proof that NoSSD was censoring blocks themselves, or if there was factual proof of nefarious intents I would feel differently and that would be a time I would consider backing something like this. But even in that case I still think it should be done directly at the community level where users on chain weight equals their vote, not through a formal process  unless it was a direct and dire threat to the security of the chain.

Here are a few reasons I think this is a terrible idea:

Censorship is one of the core things of what blockchains aim to solve. Attempting to "improve censorship resistance" through censorship is comically hypocritical.
"We are not setting a precedent that any developer can be censored." Yes you are because you are subjectively defining what is considered to "harm Chia". I would argue potentially losing 11 EiBe of netspace harms chia more than a lower NC.
I could also argue the even the proposal of such a CHIP reflects negatively on the ethos of the chain and harms Chia more than NC=6.
This directly hurts farmers that made rational economic choices to maximize farming rewards by forcing them to replot (maybe twice if new plot format comes later).
This is a bandaid solution (which I think is not a soft fork) that would require at least one more bandaid solution in your scenario of NoSSD continuing their model after a new plot format. We'd have to successfully fork in their new address at that time or more likely is they will rotate a number of reward addresses to sybil against further censorship after a replot.
As quoted, NoSSD is not violating any consensus rule. Would you also opt to censor a gigawhale farmer with a significant amount of netspace as well? Would you add other non official pooling protocol pool to this list?
Do we know for sure NoSSD is not adopting CHIP-22? Have they been given enough time to build an implementation (that would likely require their farmers to replot btw) that they are comfortable will secure their own dev fee?
"We’ve identified a bug in consensus which allows NoSSD to rapidly centralize the network" what bug are you referring to?
NoSSD is already expected to have their share of netspace drop due to GH3 and DrPlotter's better efficiency. Not to mention the upcoming plot filter reduction that may see farmers move off of compression, and even the new plot format discussions that would also address the NC indirectly.

Here are a few reasons I think this is a terrible idea:

Censorship is one of the core things of what blockchains aim to solve. Attempting to "improve censorship resistance" through censorship is comically hypocritical.
"We are not setting a precedent that any developer can be censored." Yes you are because you are subjectively defining what is considered to "harm Chia". I would argue potentially losing 11 EiBe of netspace harms chia more than a lower NC.
I could also argue the even the proposal of such a CHIP reflects negatively on the ethos of the chain and harms Chia more than NC=6.
This directly hurts farmers that made rational economic choices to maximize farming rewards by forcing them to replot (maybe twice if new plot format comes later).
This is a bandaid solution (which I think is not a soft fork) that would require at least one more bandaid solution in your scenario of NoSSD continuing their model after a new plot format. We'd have to successfully fork in their new address at that time or more likely is they will rotate a number of reward addresses to sybil against further censorship after a replot.
As quoted, NoSSD is not violating any consensus rule. Would you also opt to censor a gigawhale farmer with a significant amount of netspace as well? Would you add other non official pooling protocol pool to this list?
Do we know for sure NoSSD is not adopting CHIP-22? Have they been given enough time to build an implementation (that would likely require their farmers to replot btw) that they are comfortable will secure their own dev fee?
"We’ve identified a bug in consensus which allows NoSSD to rapidly centralize the network" what bug are you referring to?
NoSSD is already expected to have their share of netspace drop due to GH3 and DrPlotter's better efficiency. Not to mention the upcoming plot filter reduction that may see farmers move off of compression, and even the new plot format discussions that would also address the NC indirectly.

It seems you haven't examined too closely how NoSSD works and what they have done to obfuscate their key to prevent CNI from doing exactly what you propose here:

If you try to look at the NoSSD won blocks, you will notice that every single one uses a different pool public key. It is suspected that the plotter and farmer are using a deterministic approach to assigning unique public keys (Farmer public key and Pool public key) to every single plot to prevent anyone from blocking their farm from producing blocks. I have also theorized that this additionally prevents anyone from discovering them skimming because they could easily not report some won blocks.
NoSSD operates as a central farmer with all their customers as remote harvesters to that farmer, this is why they are bad for NC. The plotter automatically makes plots for their customers, they have effectively created one click farming. The NoSSD client just harvests the plots and sends the proofs to the central farmer, which then makes the blocks. The individual clients don't control anything about making a block.
If we were to publish a chip to block their farmer reward address, they would simply change it, because they are using plots made with farmer public key and pool public key. The reward address is controlled by the farmer making the block, not baked into the plot itself. They can literally change their address the second the commit is merged to a release with no action required by their clients.

Thanks for clarifying. Do you believe there is an alternative solution they could implement that would improve NC and not require a replot?

Here are a few reasons I think this is a terrible idea:

Censorship is one of the core things of what blockchains aim to solve. Attempting to "improve censorship resistance" through censorship is comically hypocritical.
"We are not setting a precedent that any developer can be censored." Yes you are because you are subjectively defining what is considered to "harm Chia". I would argue potentially losing 11 EiBe of netspace harms chia more than a lower NC.
I could also argue the even the proposal of such a CHIP reflects negatively on the ethos of the chain and harms Chia more than NC=6.
This directly hurts farmers that made rational economic choices to maximize farming rewards by forcing them to replot (maybe twice if new plot format comes later).
This is a bandaid solution (which I think is not a soft fork) that would require at least one more bandaid solution in your scenario of NoSSD continuing their model after a new plot format. We'd have to successfully fork in their new address at that time or more likely is they will rotate a number of reward addresses to sybil against further censorship after a replot.
As quoted, NoSSD is not violating any consensus rule. Would you also opt to censor a gigawhale farmer with a significant amount of netspace as well? Would you add other non official pooling protocol pool to this list?
Do we know for sure NoSSD is not adopting CHIP-22? Have they been given enough time to build an implementation (that would likely require their farmers to replot btw) that they are comfortable will secure their own dev fee?
"We’ve identified a bug in consensus which allows NoSSD to rapidly centralize the network" what bug are you referring to?
NoSSD is already expected to have their share of netspace drop due to GH3 and DrPlotter's better efficiency. Not to mention the upcoming plot filter reduction that may see farmers move off of compression, and even the new plot format discussions that would also address the NC indirectly.

As scrutinous pointed out, this is not technically viable so I wont address that. I generally agree that its hypocritical to try to improve censorship resistance via censorship, this is something that comes up a lot in public blockchains, and it becomes a blurry line when ultimately the decision is made by farmers. The same farmers would heavily benefit from a 11 EiB drop in netspace, so its not out of the questions that this would get broad support amongst farmers who are ultimately seeking financial viability of their farm. I also generally agree that decisions that this directly hurts farmers who made a rational economic decision, and appreciate that you are not taking these decisions lightly. It's to hard gauge one class of farmers incentives above another, especially when they understood the risks of a centralized entity owning their farm. This segways into the ethos discussion. When you say it would harm the ethos, its again hard to gauage of class of farmers 'ethos' over another. Its clear NoSSD farmers ethos is profit at all costs, I do wonder how far this ethos extends to the rest of the network, and how we consider what THE ethos is generally.

This is very well written and I completely understand your rationale
I just think it is the wrong direction because I have never seen censorship advance human civilization
like, ever
And for that reason I am out

I agree censorship is generally bad, but yet it is a reality we live with. Bad actors should have the right to speak, until they lose it. Law and Order is a necessary function in society, and while I love freedom of speech, i don't think there should be no form consequences to actions or proclamations that do great harm to a group. How that patterns to chia is unkown, but I am aware of many public blockchains that consider censorship as a form of punishment or dissuasion for bad actors. Of course 'bad' is subjective. But in a perfect system, the will of the majority of farmers is exercised, even if that means censorship. This is a really tough balance to strike, freedom of the farmers to run the chain vs freedom of its users to not be censored.

I'm not a fan of NoSSD because of their past behavior and the fact that they kept their tech closed source, but censorship is not the answer.
Better technology however is in the end, always the answer. NoSSD won the race because it had better tech, and farmers trying to maximize profits went to it. It will eventually fail to new better tech. GH and DrPlotter are better techs, so it's up to the farmers to switch.
Trying to pin the current low NC on NoSSD is if not malicious, at least misleading.
We want a higher NC, but the way to achieve it is through better technology and farmer adoption.
I'm disappointed in this CHIP proposal.

I can't say for sure that GH and DrPlotter will beat NoSSD, because we don't know what NoSSD has behind the scenes. They are not destined to fail. We keep underestimating them and suffer the consequences. Yes a low NC is directly because of them, if you have another take please comment but otherwise i dont believe that's a misleading statement. Is censorship the answer? Thats the question of this chip. Its unclear why you would be disappointed, after all this is a public forum to discuss ideas, you should be happy to see an idea that is a bit more controversial especially if you are against censorship.

I don’t agree with this current proposal as its completely missed the step dialogue with nossd. This proposal should only be the last resort and this chip or another one should be created to get consensus first to approach nossd to change their protocol.
As I'm not technical in side things and nossd has closed sourced software from what scrutinously said regarding blocking one address it wouldn't work anyways due to “It is suspected that the plotter and farmer are using a deterministic approach to assigning unique public keys (Farmer public key and Pool public key) to every single plot to prevent anyone from blocking their farm from producing blocks. I have also theorized that this additionally prevents anyone from discovering them skimming because they could easily not report some won blocks.”.
While I agree broadly with what was mentioned by creator of the chip I believe dialogue first is paramount instead going straight to a ban.

I feel this is a last resort, as NoSSD has not been active in discussions at all, and CNI has not shared any update on their plans for adopting chip 22, or the new plot format, which is a huge concern but less related to this chip. If you have any suggestions on interim steps we can take to help the NC or at the very least get NoSSD to communicate, I am eager to help.

I will add my two cents to this proposal.  So there may be a presumed underlying bias with my opinion. But I want to say that even if I didn't have 35 PiBe of NoSSD plots right now, I would still be against this proposal because censorship would become a slippery slope. Who gets to define what is a sufficient "problem" to block someone from the blockchain. As SlowestTimelord pointed out, an NC of 6 is likely less of a problem than being known as a blockchain that can be censored.
Second, also already pointed out, superior technology is going to be what beats NoSSD. It's analogous to freedom of speech - rather than allow the government to control speech, we have ideals that more voices with the truth will win out in the end. With this new technology (DrPlotter and GH 3.0), the better tech will win out in the end. We don't have to manipulate or force anything.
Finally, this proposal would wipe out 11 EiB of netspace if it was even possible. It would certainly stir up massive conflict with the mega-whales on NoSSD. All of this would be terrible for the health of the community and health of the network.
Even without my NoSSD farm, I would be against this proposal set forth in CHIP-32.

To answer your first question, I think ultimately the farmers decide if a problem warrants action. Being known as a chain where farmers censor bad actors is probably better than a chain where 1 entity makes majority of decisions and proposals, but both of these comments are speculative. If NoSSD 3.0 came out and was better than GH3 or DrPlotter would you switch back to that?

I agree censorship is generally bad, but yet it is a reality we live with.

Censorship only exists as long as it is supported by somebody. In this case, that somebody is you.

Bad actors should have the right to speak, until they lose it.

Who gets to decide this? I hope it's me. (Narrator: it wasn't)

Law and Order is a necessary function in society, and while I love freedom of speech, i don't think there should be no form consequences to actions or proclamations that do great harm to a group.

Language does not do harm. That's people and their physical violence that you are thinking of, similar to our government backing up laws with guns.

How that patterns to chia is unkown, but I am aware of many public blockchains that consider censorship as a form of punishment or dissuasion for bad actors.

Please list your top three examples of censorship actions on other blockchains that resulted in a net positive.

Of course 'bad' is subjective. But in a perfect system, the will of the majority of farmers is exercised, even if that means censorship. This is a really tough balance to strike, freedom of the farmers to run the chain vs freedom of its users to not be censored.

A perfect system would be one devoid of censorship. The current protocol does not meet the definition of censoring in any aspect. A new protocol that requires a new plot format for all is also not censorship any more than Apple deprecating support for an old iPhone is censorship.

I am disappointed to see this proposal. Of course we want to encourage decentralization as much as possible, but the censorship approach is misguided in spirit and problematic in implementation to say the least. I hope this proposal is forcefully rejected.

Its hard for me to sympathize with your disappointment. While this is a 'fringe' idea, I think its better to discuss in the open and run through the paces of the CHIP process than roll over out of fear of disappointing management. I care enough about the issue to spend time writing about it, and personally was very disappointed about how CHIP-22 played out, which lead to me looking for alternative solutions. Now, it's clear this solution is technically not viable, but I think you'd agree that a technically viable solution is desirable. A socially viable solution (one that doesn't break the ethos) is entirely based on how you define the ethos, and who you believe controls the chain. Ultimately farmers, a group of free think, economically motivated individuals decide what they support. In a scenario where farmers had the wherewithal to dramatically increase their profits AND a key metric on the chain, maybe they would go for it. But its unlikely to get support at the core development level, so it won't get there. Ultimately I'd like for any and all ideas to be presented to farmers so they, the ones with ultimate discretion, can decide for themselves. I apologize for the disappointment, but hope you trust that I am engaging in this discussion in good faith.

Farmers are free to pick their tools: and if you'd prefer they pick different ones... then build better ones. NoSSD isn't doing anything wrong: just offering an option that many farmers are choosing for themselves to use.
I haven't had to login to github for years: but this proposal was so poorly thought out I had to go find my creds. The idea that a project that's interacting properly with the Chia community would get censored is ludicrous.

In the same vein, farmers are free to censor an entity if they so chose, if it benefits them. Im sorry you felt this was poorly thought out, it was definitely cooked up in a few hours but I felt it was a really important discussion to be had. You proved that by logging in to comment! And I disagree that NoSSD is interacting properly with the Chia community, and I believe I'm in the majority there.

I think scrutinous made some strong points on the tech side of things why this won't work, and it seems max thinks so as well. Since this seems to be a more community oriented chip, and I feel there are repercussions in general just from the ideas mentioned in, I will still post my thoughts around it that may be more "lateral" to the actual proposal.

While NoSSD does hurt the NC of the chain, they are still operating within the bounds of consensus and have not shown in any way they are a bad actor. There are no requirements for them to "dox" themselves  given the ideals of bitcoin, ideals that chia inc has mentioned they based the chain on, and the general ideals supported by the community reflect this.
As mentioned by others, farmers running evergreen light farmer also use a centralized node that get to choose what foliage to include with the block. Going back to the ideals and bitcoin and blockchains in general, this is a permissionless
system. No one should be assumed to be a good or bad actor, this is all handled by consensus. If there was a case of block censoring  or if the community as a majority had issues with NoSsd they could choose to attempt to reject NoSsds blocks to counter it, but most would not want unless given a strong reason. Being a permissionless chain, the node that evergreen farmers use can be deemed to be just as much of a good or bad actor as NoSSDs node, without any proof to show otherwise.
If Chia Inc. were to implement any code to fork out NoSSD if even possible, it would make a strong argument that they are are centralized arbiter of the chain. The only way it could be seen otherwise would be if such a chip had near universal community support. Touching on this even more, the fact that NoSSD exists running either their own node, or a modified node leveraged for their own intent and purposes helps establish Chia the blockchain as a community driven effort  and shows that Chia Inc. does not act as a centralized entity controlling the chain.
Touching more on point 4, if Chia Inc. were to implement censorship at any point, it would be setting a non-legal, but still strongly arguable precedent that they can censor the chain. This means if there is ever a case where a government entity were to request censorship in any situation, Chia Inc could be found to be legally liable if choosing not to do so, as they would have done so before in other context and wielded such power . This is a big point being overlooked in a proposal like this. As such, implementing a chip like this would have many ramifications for both Chia Inc, and the community as a whole. For Chia Inc. it would be in the legal sense, for the community it would be a "First they came for ____ and I did not speak out." But over all in my opinion nothing to do with it would better the chain in anyway and in every case other than the NC number it harms the chain.
While I don't know your intents for this chip, and don't want to make any assumptions, I think from a business standpoint even submitting such a chip looks really bad. You run a company where near all of your farmers don't run a node, NoSSD offers the same. If there was a situation where they were knocked off chain via NoSSD being blocked, the fall back would be fast farmer. While this doesn't mean evergreen would profit directly and they would have any reason to purchase from evergreen, there is a very important aspect here, that fast farmer would be a viable alternative. Fast farmer was developed IIRC via a grant from Chia Inc. Fast farmer also implements competing compression from MadMax, and as such when a farmer uses fast farmer with GigaHorse compressed plots, part of the fees go to the developer of fast farmer. While I don't know exactly how fast farmer development is tied to EverGreen or anything around the usage of the fees garnered by it use, this seems like a fairly large conflict of interests. Given what I outlined above it could be argued that the motives behind this chip could be rooted in this conflict and it could be argued that as such this chip is being used as a form of regulatory capture. I will state once again, I don't know your motives and I am not accusing you of this or think that is the reasoning for the chip, it needs to be pointed out.
As a permission-less chain no one should have to assume anyone's motives and as such I feel like such a chip, that aims to implement this through Chia Incs. own proposal process is not the place to take such actions. As outlined above, NoSSd could have their own motive, EverGreen may have their own motives, and to preemptively take actions around assumptions goes against the natural and ideals of blockchains and their community. If you or anyone else feels they should take action against NoSSD, anyone can do so right now via an edit to the open source client. People are free to take actions and vote via what they choose to validate. This would make the process of "forking" or "invaliding" not a top driven endevour. While I have stated blockchains and their community have ideals that normally don't align with censorship that everything should be permissionless and and assumptions of whether someone is good or bad should not be required, users are still capable of taking these assumptions and taking action through the weight of their own participation, but any form of it not being a community driven, decentralized effort, seems to be the wrong approach, and my IMO an improvement proposal  leveraging Chia Inc for the implementation is the wrong place for such an action. If there was actual proof that NoSSD was censoring blocks themselves, or if there was factual proof of nefarious intents I would feel differently and that would be a time I would consider backing something like this. But even in that case I still think it should be done directly at the community level where users on chain weight equals their vote, not through a formal process  unless it was a direct and dire threat to the security of the chain.

EditL
Also to address the point made that NoSSD chose not to implement CHIP-22, which I personally don't think is grounds for blocking them either way. Chia-22 has been in the client for around 2-3 weeks? Even less as the release was rolled back for part of that time. So it's really soon too soon to judge if they will implement it or not. So I think its misleading at best to say they chose not to implement it.

Im very disappointed that a crux of your argument points to how Evergreen handles their fleet of decentralized devices. I don't believe this is related to NoSSD, and is an attack on the author, not the argument. I didnt even mention Fast Farmer, and believe that the better tech will win. I am speaking for a subset of farmers who of course would want to see their farm rewards increase by ~30% quickly, and see a rapid rise in the NC. Your post points out how Chia Inc is reponsible for changes getting pushed and could be held liable. This is ironic, because to my understanding Chia Inc does not have unilateral decision making about what gets merged into their client. I believe that is what the CHIP process is for, which is why I proposed this as a CHIP. I am eager to understand what threshold of proof that NoSSD is a 'bad actor' it would take for the community to vote. I am not sure there is a mechanism to do that today, so we are really left with CNIs opinion of NoSSD and their willingness to pursue a path that goes against their ethos. This is all moot given it is not a viable technical solution, however I am glad you brought up several points of concern that I believe need to be addressed regardless of this CHIP.

I agree censorship is generally bad, but yet it is a reality we live with.

Censorship only exists as long as it is supported by somebody. In this case, that somebody is you.

Bad actors should have the right to speak, until they lose it.

Who gets to decide this? I hope it's me. (Narrator: it wasn't)

Law and Order is a necessary function in society, and while I love freedom of speech, i don't think there should be no form consequences to actions or proclamations that do great harm to a group.

Language does not do harm. That's people and their physical violence that you are thinking of, similar to our government backing up laws with guns.

How that patterns to chia is unkown, but I am aware of many public blockchains that consider censorship as a form of punishment or dissuasion for bad actors.

Please list your top three examples of censorship actions on other blockchains that resulted in a net positive.

Of course 'bad' is subjective. But in a perfect system, the will of the majority of farmers is exercised, even if that means censorship. This is a really tough balance to strike, freedom of the farmers to run the chain vs freedom of its users to not be censored.

A perfect system would be one devoid of censorship. The current protocol does not meet the definition of censoring in any aspect. A new protocol that requires a new plot format for all is also not censorship any more than Apple deprecating support for an old iPhone is censorship.

That somebody would be the farmers. A perfect system would exercise the will of the farmers, in which they are free to censor anything they like. Language (content) gets censored all the time on the internet, and I believe blockchains are a way to go beyond that. However farmers can, and will censor what they don't support, it inevitable as people will try to push the limits of the content that can go on a distributed network. Great discussion but don't want to get too far off topic.

I am eager to understand what threshold of proof that NoSSD is a 'bad actor' it would take for the community to vote. I am not sure there is a mechanism to do that today

The mechanism today is that you first "print the ballot" by making a fork of the Chia blockchain with your proposed chain. Voting then is how many downloads you can get vs the original.
If you can't even technically "print the ballot" then we aren't going to be able to ever vote.

It won't work.

Not with that attitude ;)

Not with that attitude ;)

But with magical thinking? If anything you allow NoSSD to play the victim now, well played.

I don’t agree with this current proposal as its completely missed the step dialogue with nossd. This proposal should only be the last resort and this chip or another one should be created to get consensus first to approach nossd to change their protocol.
As I'm not technical in side things and nossd has closed sourced software from what scrutinously said regarding blocking one address it wouldn't work anyways due to “It is suspected that the plotter and farmer are using a deterministic approach to assigning unique public keys (Farmer public key and Pool public key) to every single plot to prevent anyone from blocking their farm from producing blocks. I have also theorized that this additionally prevents anyone from discovering them skimming because they could easily not report some won blocks.”.
While I agree broadly with what was mentioned by creator of the chip I believe dialogue first is paramount instead going straight to a ban.

I feel this is a last resort, as NoSSD has not been active in discussions at all, and CNI has not shared any update on their plans for adopting chip 22, or the new plot format, which is a huge concern but less related to this chip. If you have any suggestions on interim steps we can take to help the NC or at the very least get NoSSD to communicate, I am eager to help

I will add my two cents to this proposal.  So there may be a presumed underlying bias with my opinion. But I want to say that even if I didn't have 35 PiBe of NoSSD plots right now, I would still be against this proposal because censorship would become a slippery slope. Who gets to define what is a sufficient "problem" to block someone from the blockchain. As SlowestTimelord pointed out, an NC of 6 is likely less of a problem than being known as a blockchain that can be censored.
Second, also already pointed out, superior technology is going to be what beats NoSSD. It's analogous to freedom of speech - rather than allow the government to control speech, we have ideals that more voices with the truth will win out in the end. With this new technology (DrPlotter and GH 3.0), the better tech will win out in the end. We don't have to manipulate or force anything.
Finally, this proposal would wipe out 11 EiB of netspace if it was even possible. It would certainly stir up massive conflict with the mega-whales on NoSSD. All of this would be terrible for the health of the community and health of the network.
Even without my NoSSD farm, I would be against this proposal set forth in CHIP-32.

To answer your first question, I think ultimately the farmers decide if a problem warrants action. Being known as a chain where farmers censor bad actors is probably better than a chain where 1 entity makes majority of decisions and proposals, but both of these comments are speculative. If NoSSD 3.0 came out and was better than GH3 or DrPlotter would you switch back to that?

Yes, you raise a good point here.  NoSSD might release version 3 -- who knows, it might be even more efficient than Pro4x or GH 3.0 -- and if it is, I'm a greedy farmer.

Im very disappointed that a crux of your argument points to how Evergreen handles their fleet of decentralized devices. I don't believe this is related to NoSSD, and is an attack on the author, not the argument. I didnt even mention Fast Farmer, and believe that the better tech will win. I am speaking for a subset of farmers who of course would want to see their farm rewards increase by ~30% quickly, and see a rapid rise in the NC. Your post points out how Chia Inc is reponsible for changes getting pushed and could be held liable. This is ironic, because to my understanding Chia Inc does not have unilateral decision making about what gets merged into their client. I believe that is what the CHIP process is for, which is why I proposed this as a CHIP. I am eager to understand what threshold of proof that NoSSD is a 'bad actor' it would take for the community to vote. I am not sure there is a mechanism to do that today, so we are really left with CNIs opinion of NoSSD and their willingness to pursue a path that goes against their ethos. This is all moot given it is not a viable technical solution, however I am glad you brought up several points of concern that I believe need to be addressed regardless of this CHIP.

I am sorry you are disappointed and take the mention  of conflict of interest or how parallels of your own business tie into this as a personal attack and that they should be dismissed.
You even mention in another comment:

Thanks for clarifying. Do you believe there is an alternative solution they could implement that would improve NC and not require a replot?

Which makes this seem more like it is related to your business offerings, as there has not been a single vocal supporter of these measure. You have mentioned your concerns around having to re-plot your customers as well. While other in the community may share this concern, so far no-one has and it would be every welcome for them to state so here if they feel that way.
That said the NC is not the reason for Chia Inc. wanting to implement a new plot format, this is rooted in the security of the chain, and it has been down that 6-10 after launch there would likely need to be a re-plot to address security.
By bringing this into a CHIP proposal, it is quite valid address parallels and conflicts of interests as you are now escalating these ideas one step further into implementing them in practice. I hope you don't take what I say as a personal attack, and I am making my points and arguments in good faith from a neutral, yet critical context as this is how a CHIP should be approached. The context of which is I don't know your motives if any, and I don't know NoSSDs motives, some of which have been presented as assumptions in your CHIP, which is also arguably is a personal attack NoSSD and is making baseless accusations at points. I will address the points you brought up and hope you can understand I am not attacking you and understand given this is a proposal process, some things do need to be reviewed critically. I also don't like that this is how this CHIP needs to be addressed, but it comes with the nature of a very impactful change being proposed that has nothing to do with actual tech, and is solely based around sentiments outside of nakamoto coefficient, which is still not being address from a true technical change other than a coordinated strong armed action against  30% of the network and a single entity

I didnt even mention Fast Farmer, and believe that the better tech will win.

It doesn't matter if you mentioned Fast Farmer or not, you can't expect a conflict of interest not to be brought up just because you didn't mention it. If anything not addressing it explicitly in your CHIP is a cause of more concern not less.
You can't claim you believe the better tech to win, yet your are submitting a chip that would strong arm a lateral competitor out of the space. Like I said I do not think this is your reason for this chip, or am accusing you of that. Im addressing this only as a fact of existence, and it should be known to all reading this chip there is a conflict on interest here. Outside of foxy farmer the only other  alternative for users wanting to farm node-less are these 2 clients. One of which is fast farmer and is the closest Parallel  to NoSSDs farmer.
I would argue you do need to address the conflict of interest, even more so that you are now submitting a chip that would fork out the competitor directly through chia, who also gave your business a grant to develop it. This also further adds to the fact that in the case Chia inc directly implemented such a chip it would show centralized control of the chain by Chia Inc. As they would then be forking out a competitor to a product they helped fund.

I am speaking for a subset of farmers who of course would want to see their farm rewards increase by ~30% quickly, and see a rapid rise in the NC.

There is little to say here other than the argument this is good because it increases rewards for other farmers at the expense of others seems inconceivable to me as a good and fair argument. They are not exploiting the chain, every thing is valid consensus, the only reasoning here is the NC and wielding power to increase the rewards of some at the expense of others.

Im very disappointed that a crux of your argument points to how Evergreen handles their fleet of decentralized devices.

I don't see how this is disappointing and not a valid point. Most of your companies users are not choosing what transactions to include either, for all anyone knows the node they are running already doesn't include NoSSD blocks, or could have any type of arbitrary control over what gets included. Its not a 1-1, as your users do get the choice of picking a node, but it is still fully valid to mention this parallel imo.

Your post points out how Chia Inc is reponsible for changes getting pushed and could be held liable. This is ironic, because to my understanding Chia Inc does not have unilateral decision making about what gets merged into their client. I believe that is what the CHIP process is for, which is why I proposed this as a CHIP.

I very well may have a misunderstanding of CHIPs, but from my understanding they are to submit an implementation and sometimes an idea for chia to implement into their client. There is no reason to bring a chip if you have a service or product that interacts with the chain that isn't looking for direct protocol implementation or software support via Chia Inc.
Like said by Dan Perry, Chia Inc doesn't get to choose if people support those changes, as its still the community that choose to run them. But just the act of Chia Inc implementing a change does mean Chia is trying to influence the chain in that manner. And implementing a direct ban of NoSSD would be them attempting to use the influence in a non neutral way, not tied to a technical improvement. I don't think chia would touch implementing a proposal like this, unless it had near full support of the community and even then I assume they'd be weary.

I am eager to understand what threshold of proof that NoSSD is a 'bad actor' it would take for the community to vote. I am not sure there is a mechanism to do that today, so we are really left with CNIs opinion of NoSSD and their willingness to pursue a path that goes against their ethos.

I'd say the start would just be any proof, claims take evidences. And going back to the ethos, it seems a large part of the community feel like the ethos of non-censorship is more important than the NC . The threshold of proof it would take for me to agree that NoSSD is a bad actor, is the same as it would take for me to believe evergreen were a bad actor when it comes to including transactions in their provided node.
That said with NoSSD there is the fact that they also sign the block, which is a huge difference than just censoring transactions. I bring up that many evergreen farmers are also using a centralized node that chooses the foliage as that was what was mentioned in your CHIP. But I do agree that there is a valid concern around the fact that NoSSD also signs the blocks as well and farmers can't just easily switch. That said I don't think this is a concern given no proof and they are still a good bit away from the threshold where they could attempt any kind of attack on the chain.
I hope you understand why I have to bring parallels of your business operations into this discussion, as these are concerns behind the motive and possible conflict of interest. In the case of this chip, as you are a representative of a business presenting a non technical proposal that solely targets another party, I can't focus solely the argument being made as that argument is not for implementing some form of technical change that can reviewed solely from a technical level. I have stated how I personally feel around censorship on the chain and well as others. But when submitting something as drastic as forking out a specific entity you have to review the possible motives behind it.
I personal don't think you have hidden motives, but these issues and conflicts of interest have to be addressed, brought up and known to those reading this discussion and during the consideration of such a proposal. We can't expect Chia and the community to hold up a ethos of transparency and not bring this up. I don't know your true motive, I don't know NoSSDs true motives. All I know is that there is a good case of a conflict of interests around Fast Farmer and such a chip would benefit you financially as well as other competitors in the compression space . I  can't personally consider the chip as separate from your business offerings, while you may very well be doing this solely from your personal stance in the community. No one else has yet to support this chip, discussions on twitter before hand had no vocal support, so its easy to assume there is business motive behind it.
Either way starting a chip process is going to involve critical review of both the tech and impact. As being solely a CHIP targeting  30% of the network and against a single entity in the business sense, the critical review is going to center around possible motives and how it affects the chain and community as a whole. You can't represent a business, and bring a proposal advocating a ban of a personal entity on the chain even if they are unknown and then wonder why personal conflicts of interest and motives are being  brought up.
The more I think about it, this 100% shouldn't be a CHIP, as everything about this is personal, there is no technical change or improvement offering. It is solely based around an ___ vs them argument and everything about this would increase or decrease personal rewards of individuals themselves and directly target a participator of the chain based on nothing but  unproven assumptions and maybes.
AS I've stated before I personally think this is something user should do themselves, or should be done separate from Chia Inc. And it seems it can technically even be done via a top down change. But if users want to play wack-a-mole with NoSSD the client is open source and there are various was detached from Chia Inc for the community to shape their own consensus.
I personally don't mean any of this as an attack on you, I'm just trying to have a critical discussion I'd honestly rather not have. I think your business has done a lot for the chain, and I have no hard feels. I honestly wish you hadn't brought this chip as I feel like it is very shortsighted and hurts evergreen optics more than anything. But also a CHIP process escalates the idea more than just a discussion happening in a twitter space, and thus opens up  the need for critical and dissective review.

我认为这不是一个好的想法，我不支持这个想法。

Others have more eloquently expressed my concerns. I am strongly against this proposal.

I don't want to talk on the merits of the conversation as this is all a trolling taken way too far IMO. I do have an important question for @danieljperry here. Do we give a CHIP number to technically impossible ideas?

....

Either way... I hope this chip stays up. Censorship will be proposed again, and the community comments and sentiment here needs to stand as a warning to others.

I enthusiastically support NoSSDs right to be as toxic as they want 👍

I don't want to talk on the merits of the conversation as this is all a trolling taken way too far IMO. I do have an important question for @danieljperry here.

Yes. They are given the number √-1 , √-2 , etc.

In response to a few of the comments here, CNI (Chia Network, Inc.) has not yet taken a stance on this CHIP, though some of its employees have.
Even if this CHIP were to be finalized, CNI would be under no obligation to add it to their code base. This is true for all CHIPs, and all software vendors.
If the CHIP were finalized, and CNI agreed with it, then the company would add it. If it got to this point, then there would (by definition) already be consensus from the community, and it would be adopted.
However, if the company disagreed with it, then the company would ignore it (even after it was finalized). In this case, if someone else wanted to adopt it, they could either fork CNI's code, or write their own client that included the CHIP, and push for community adoption thereafter.

Releases overpriced evergreen miner hardware (but make it simple to use as a value add)
Cant compress plots much to make competitive due to low power nature of said hardware
Non evergreen miner compression levels have reached nonsense levels so a complete replot using a different format is being explored by CNI (this replot part is a good idea)
Evergreen doesnt want to issue refunds or replot existing hardware (by having their customers mail them) so they suggest just blocking one of the four compression vendors.

Did I get this right?
The new plot format is the best change. Just let your customers mail you the hardware they purchased and replot it for them. Your margins appear high enough to support this all things considered. Or just turn off the website...

I don't want to talk on the merits of the conversation as this is all a trolling taken way too far IMO. I do have an important question for @danieljperry here.

Yes. They are given the number √-1 , √-2 , etc.

Interesting. I have some additional thoughts around that specifically I will put in a less derailing the thread place. Would hate to see the CHIP process get gamed for marketing purposes and a few other things that jump out around this.
Seeing as it iss being taken seriously then I will add a hard NO on blockchain censorship in all forms, including this one.

Yes. They are given the number √-1 , √-2 , etc.
That was my attempt at a joke (those are imaginary numbers).

Back to being serious.

Back to being serious. I'm not here to judge whether the CHIP is a good idea. The reason it got assigned a number was because it met the threshold of becoming a CHIP that was outlined in CHIP-1. One could argue that it is not valuable or congruent, but those would be subjective judgements. It might also not be feasible, but this wasn't brought to our attention until after the number was assigned. And I don't think this has been confirmed yet.
I have rejected many other attempts at CHIPs because they didn't meet this threshold. If someone tries to game the system, then either their proposals will be rejected, or they will have provided a potentially valuable idea to the community. And simply assigning a CHIP as a draft is in no way an endorsement of the ideas contained within.

I'm just wondering about the reference implementation aspect of it. I actually like having the discussion on it archived here. The CHIP didn't appear to present a reference implementation code for the patch in question, or is it fine to fill in those details in a CHIP as it progresses?

I'm just wondering about the reference implementation aspect of it. I actually like having the discussion on it archived here. The CHIP didn't appear to present a reference implementation code for the patch in question, or is it fine to fill in those details in a CHIP as it progresses?

A working reference implementation would be required in order for the CHIP to be moved to the Review phase. It's not required for a Draft, though the way in which it might be implemented needs to be written. Which it is in this case. If it turns out not to be possible to implement this CHIP as outlined today, either Dylan will need to come up with a different way of doing it, or withdraw the CHIP.

Well file this under TIL I have not suggested several ideas as I thought I had to have a working prototype! Great to know.

Well file this under TIL I have not suggested several ideas as I thought I had to have a working prototype! Great to know.

Sorry this wasn't clearer. Looking forward to seeing those ideas!
Caveat it needs to be "We plan to build this thing. We have not fully built it yet, but we do have a good idea of how to do so, as demonstrated here."
If it's "I want someone else to build this thing," then it should be a feature request.

@evergreendrose On Discord you indicated that you wanted to withdraw this CHIP due to it not being technically feasible. Can I get you to confirm that here? If so, I'll handle the rest.

Yes! Thank you.
On Mon, Mar 18, 2024, 6:03 PM Dan Perry @.***> wrote:

@evergreendrose https://github.com/evergreendrose On Discord you
indicated that you wanted to withdraw this CHIP due to it not being
technically feasible. Can I get you to confirm that here? If so, I'll
handle the rest.
—
Reply to this email directly, view it on GitHub
https://github.com/Chia-Network/chips/pull/111#issuecomment-2005373436,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUXTPED2AKZSO2ZU4EC2Z7LYY56FDAVCNFSM6AAAAABEZ4TZZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBVGM3TGNBTGY
.
You are receiving this because you were mentioned.Message ID:
@.***>

This CHIP is now Withdrawn. No further changes are allowed. However, a new CHIP with similar contents could, in theory, be opened in the future. Therefore, this CHIP's history will be preserved here.

This is very well written and I completely understand your rationale
I just think it is the wrong direction because I have never seen censorship advance human civilization
like, ever
And for that reason I am out

I agree censorship is generally bad, but yet it is a reality we live with. Bad actors should have the right to speak, until they lose it. Law and Order is a necessary function in society, and while I love freedom of speech, i don't think there should be no form consequences to actions or proclamations that do great harm to a group. How that patterns to chia is unkown, but I am aware of many public blockchains that consider censorship as a form of punishment or dissuasion for bad actors. Of course 'bad' is subjective. But in a perfect system, the will of the majority of farmers is exercised, even if that means censorship. This is a really tough balance to strike, freedom of the farmers to run the chain vs freedom of its users to not be censored.

What gets done on-chain should be dictated by the code of the chain. Any other form of arbitration is bound to end poorly.
We don't want to be a blockchain or community that claims code is law, but hypocritically seeks out human arbitration.
Such chains tend to centralize and lose their vitality, k?


Serialization Example

Is it possible to serialize the entire grid into a JSON object?
In the gridster.js library, the given example is simply gridster.serialize();. Is there something that simple with angular-gridster?
This would be something good to have easily visible in the README.

I also struck here. Please help with code example

this is my code in the main controller that containing the gridster:
    $scope.saveDashboardLayout = function saveDashboardLayout() {
        sessionStorage.userDashboardLayout = angular.toJson($scope.standardItems);
    };

    $scope.loadDashboardLayout = function loadDashboardLayout(){
        $scope.standardItems = angular.fromJson(sessionStorage.userDashboardLayout);
    };

where the - $scope.standardItems - is the array of widgets that the gridster is doing ng-repeat on them:
$scope.standardItems = [{
name: 'Widget2',
sizeX: 3,
sizeY: 2,
row: 2,
col: 4
}, {}, {}, {}....]

This code:
`    $scope.saveDashboardLayout = function saveDashboardLayout() {
sessionStorage.userDashboardLayout = angular.toJson($scope.standardItems);
};
$scope.loadDashboardLayout = function loadDashboardLayout(){
    $scope.standardItems = angular.fromJson(sessionStorage.userDashboardLayout);
};`

Return: [object Object],[object Object].....
Why not return this: $scope.standardItems = [{
name: 'Widget2',
sizeX: 3,
sizeY: 2,
row: 2,
col: 4
}, {}, {}, {}....]
Where is the problem?


finetuning inception_v3

finetuning resnet18 as
train: models.resnet18(pretrained=True)
val:   models.resnet18()
But while finetuning inception_v3 as above, I got poor result. The valuation must be
val:   models.inception_v3(pretrained=True)
I spent much time stucking here..

Hi,
I have never been able to train / finetune inceptionV3, nor do transfer learning with it.
The pre-trained weights have been converted from TensorFlow, and might have required external data / intermediate classifiers to be able to train it properly.
I would recommend using ResNet / ResNeXt models, which are well understood and give good results.


theory and practice mixing

shorter theory, shorter exercises
eg, file reading > go directly to file reading
in general, take into account that for afternoon sessions : need to simplify exercises

the day1 afternoon and day2 morning practical have been split in several parts