-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't display protocol inscriptions on homepage #2674
Conversation
0fc9c46
to
b1b9eb2
Compare
b1b9eb2
to
62fb3d8
Compare
The number of .bitmap inscriptions post blockout is minimal, presenting no major concerns. Introducing bias into the ord client is a slippery slope. If brc-20 dominate the front-page so be it. "The spirit of the people is greater than the Man’s technology" |
I don't think it's a slippery slope. All the inscriptions which are hidden from the homepage are really objectively not interesting to look at. BRC-20, bitmap, and gib inscriptions are protocol messages, and the overwhelming majority of users don't care about them, and will benefit from seeing a more interesting stream of inscriptions. The old homepage is still available under |
I acknowledge the rationale behind pruning BRC-20 inscriptions, yet, from an objective standpoint, the unfiltered view of what's being inscribed offers a more intriguing insight for me personally. Deciding what is shown should be left to third party apps and marketplaces. Anecdotally, I was introduced to ordinals as a new way to grift PFP projects, I did not become interested until metaprotocols like .bitmap which is a highly efficient use of blockspace, more in-line with the ethos of bitcoin and satoshi who inscribed text to the genesis block, not jpegs. Filtering by content type could be one approach, but hand selecting winners and losers is creating a president for a ban list which will continue to grow, or will go into 1.0 with a hard coded bias being shown against .bitmap and gib selectively which represent less than 1% of daily inscriptions |
I strongly support explorers choosing to display inscriptions differently according to their design goals. This is in line with my view that we have several layers: the protocol Just like Ordinals is a "lens" you view Bitcoin through, explorers are a "lens" you view Ordinals through. I think it not only makes sense for ordinals.com to filter inscriptions as it sees fit, I think it sets a good example for the ecosystem & other explorers. |
I agree to an extent, but the role of ordinals.com IMO is to show what's happening on-chain, not what we want to be happening on-chain. De-ranking .bitmap seems more like a KEK and i don't think that sets a good example at all, considering there are only around 150 blocks per day, i'd personally rather see a few .bitmap inscription on the front-page than someones half baked pfp project. Also new users will be unaware of this code change as it will not be denoted on the front page in any way, creating a colored view of ordinals. That being said, you could drastically improve the front-page and avoid creating an ever growing ban list by simply hiding BRC-20, which most will be in favor of. In this case I still think it should be clarified somewhere that this filter is being applied. Even in the case of BRC-20 trying to play whack a mole is a futile effort and not future proof as there could easily be another objectively not fun to look at protocol to replace it. So this PR will only serve as a relic of opinionated decision making |
I was under the impression the design goals of ordinals.com was to serve as ground truth for ordinals. Is this no longer the case? Rather than pruning, why not add filters in the front-end? I purposefully designed bitmap to NOT use JSON files, and instead use simple text, largely because I thought JSON looked ugly on ordinals.com. This was my concern from the beginning. I think the bitmaps are beautiful in their raw form, personally. The change has no bearing on the success of Bitmap of course, but it does display a clear bias towards certain kinds of inscriptions. |
There's no pruning, literally just a filter on one page of ordinals.com. You can still see all bitmaps and brc-20 if you go to the blocks page or inscriptions page |
Also, there are way more than 144 |
@Blockamoto by pruning i meant trimming (from front-page). Still there's no real argument here other than "we don't like seeing bitmap" there's a million other protocols, tap, orc-20, brc420, brc100. What will the next bitmap be? will you have to then keep pushing filters? It's not the job or ordinals.com to act as a marketplace or to beautify the front page. it's a blockchain explorer, of sorts, Intertwined within the client (for better or for worse) and as block mentioned: The expected source of truth for ordinals protocol. If I want to see pretty stuff i can visit a number of other explorers and front-ends where biases are expected. As a users, i specifically visit ordinals.com to see unfiltered information, I want to see which brc-20 are being minted and traded, it gives me insight. And although it may be available to see on the blocks page, it will be misleading if not explicitly stated that the front-page is filtered. A solution could be toggles to filter by content type or a toggle which applies the filter which includes the short list of hand selected things that the core dev team doesn't want to see |
"It makes the homepage ugly." is a valid argument. People go to to the homepage of ordinals.com, and their own
Whenever a protocol gets popular enough to make the homepage ugly, we will add a filter. Filters are one-line changes.
It is not the job or ordinals.com to act as a marketplace, but it is the job of ordinasl.com to beautify the front page.
You can also visit the
The homepage doesn't say "these are the latest unfiltered inscriptions", it just presents 100 inscriptions. I don't think it's particularly misleading. |
I believe this is a common view because users have trouble differentiating between what is protocol, implementation of the protocol, and explorers of inscriptions using the reference implementation of the protocol. It's also my personal opinion that the developers of the reference implementation have not done a good job communicating the difference between the protocol and reference implementation, in fact often conflating the two. I think this is one reason why the adjustments to the landing page of the ordinals.com is controversial, because these different elements have not been sufficiently distinguished. That said, I think demonstrating that Explorers should customize how they "interpret" Inscriptions is both a good design decision & leadership for the ecosystem. In the same way that ordinals.com may want to filter certain text & JSON from the landing page, other explorers may want to only show those. I would argue some tools like GeniiData are actually also explorers, just selecting to focus on JSON/metaprotocols. I think there should be consensus on protocol, expected similarities but not necessarily consensus on implementation, and wide diversity among explorers. |
My only point is playing whack-a-mole is futile and selectively bias. Once development is finalized on ordinals, which i believe is the goal - you will have this short-list of things you tried to disappear and it's not going to age well. Filtering by content type, having toggles, or some other solution like showing the largest file sizes could be more fun and future proof. Personally I don't care about peoples pixel punks, so who's to say what's valid. @cbspears to your point about leadership, as someone involved with .bitmap community, we already have to deal with sanctimonious attitudes, having that co-signed even in this small way is not ideals. Very reminiscent of bitcoin maxis saying ordinals are a waist of space |
It's not futile. Filters are one-line changes. The filter for BRC-20 also catches all JSON protocol inscriptions.
Most users support this change. It's going to age fine.
We have a toggle. It's called clicking the "Blocks" tab.
We aren't saying that |
I want to keep this focused on the specific topic of what to display on the ordinals.com explorer, but to your point on sanctimonious attitudes, condescension I may communicate about .bitmap -- I've been very critical of Inscriptions as a mechanism for namespace in general as I believe these metaprotocols are structurally flawed long term. That doesn't mean that I'm against namespaces in general, in fact I think that's one of the most underexplored developments on Bitcoin. It also doesn't mean namespace & fungible token protocols won't have significant value accrual in the short term either. I strongly believe that valid transactions, however dumb I may consider them, are important buyers of Bitcoin blockspace and I strongly believe we should allow price discovery of these assets, however stupid I may think they are. It's like the quote from Evelyn Beatrice Hall on Free Speech "I disapprove of what you say, but I will defend to the death your right to say it." just instead about using Bitcoin. That is a far cry from anti-Ordinals crowd many of whom wish to censor or prevent ordinals-related transactions at the protocol level. That doesn't preclude filtering certain types of Inscriptions from the frontend of an explorer. I will probably even buy some bitmaps just to enjoy the ridiculousness of it all. Unfortunately most internet discourse is reductive & binary so I often don't go into nuanced detail in a forum format as I can here. I think that most bitmap enjoyers are probably just not aware of the technical shortcomings to the protocol and confuse technical criticism with personal & interpret price increase as invalidation of the technical criticisms. The Bitmap community is one of the most prolific builder groups in the space. I think it makes way more sense to design for bitmap-focused explorers than to try to lump everything into the same category on a landing page. |
You shield yourself nicely from actually having to explain yourself regarding "technical limitations" by claiming it has nothing to do with your opinion that ordinals.com homepage should filter out metaprotocols from the homepages raw feed. If you actually want to challenge the protocols technical standing, I'm happy to have this discussion wherever whenever. It could be that the shortcoming is not with the thousands of people who have come to a different conclusion. I think beauty is in the eye of the beholder, and it's okay that you think bitmap is ugly. When I created it, to me it was the most beautiful thing I'd ever seen, but we can beg to differ. |
Ok well I stated my case and I support good work you guys are doing @casey
@cbspears I'd love to debate about this, but for sake of casey and raph time, I will rest my case and say that I support all the great work being done to ordinals, even if i disagree here. I personally rely on ordinals.com for unfiltered information and from a UIX perspective it's really confusing and not apparent that /blocks/ will serve different information than the front page, which is visually presented as an explorer, not a curation. The .bitmap namespace has no technical shortcomings. It is just a text inscription. As i said before Satoshi himself added text to the genesis block. Ordfluencers jumping over from ETH and Solana, dismissed it due to bag biases and confusion why liquidity was flowing into a simple text file and not their PFP projects. By using Bitcoin as a verification layer, we can query block data off-chain to visualy represent .bitmap in any way, making it a highly versatile and compact use of block space. I have a very long history developing in crypto space and developing on EVM, have won multiple hackathons etc. To me bitmap is one of the most interesting ordinals projects with 800k supply, 30k holders, numerous decentralized developers. That is not found anywhere else. The sat hoarders and gatekeepers will argue that "uncommon sat" ownership gives you the block, which is great, but convince 30k people of it and then implement it. The social consensus supports .bitmap, aligning with Bitcoin's intended purpose as a verification tool. |
* Fix lost sats bug (ordinals#2666) * Add Hindi version of handbook (ordinals#2648) * Remove Index::index_block_inscription_numbers (ordinals#2667) * Hide protocol inscriptions (ordinals#2674) * Don't color links in headers (ordinals#2678) * Add inscription charms (ordinals#2681) * Group rune server tests (ordinals#2685) * Add inscription compression (ordinals#1713) * Fix media table formatting (ordinals#2686) * Update schema version for charms (ordinals#2687) * Fix unbound outpoint server error (ordinals#2479) * Add binary media type (ordinals#2671) * Clean up install.sh (ordinals#2669) * Add /collections Page (ordinals#2561) * Preview font inscriptions (ordinals#2692) * Only load used language highlight module in code preview (ordinals#2696) * Only try to create the database if it wasn't found (ordinals#2703) * Move postage into batch file (ordinals#2705) * Add destination field to batch (ordinals#2701) * Use sequence numbers database keys (ordinals#2664) * Update redb to 1.4.0 (ordinals#2714) * Refactor inscriptions paginations (ordinals#2715) * Display table stats in `ord index info` (ordinals#2711) * Use redb's recovery callback API (ordinals#2584) * Allow setting CSP origin (ordinals#2708) * Remove default file path from `ord index export --tsv` (ordinals#2717) * Use icons in nav bar (ordinals#2722) * Add Debian packaging instructions (ordinals#2725) * Add Homebrew install instructions to readme (ordinals#2726) * Add sat recursive endpoints with index and pagination (ordinals#2680) * Only accept sat number in recursive endpoint (ordinals#2732) * Fix typo in docs/src/inscriptions/metadata.md (ordinals#2731) * Add docs for metadata recursive endpoint (ordinals#2734) * Remove `RUNE` from <h1> on /rune (ordinals#2728) * Add /r/children recursive endpoint (ordinals#2431) * Add docs and examples for sat recursive endpoint (ordinals#2735) * Ignore flaky test (ordinals#2742) * Update docs to include all fields, including content-encoding (ordinals#2740) * Add docs for child recursive endpoint (ordinals#2743) * Hide JSON and .btc (ordinals#2744) * Release 0.12.0 (ordinals#2746) --------- Co-authored-by: raph <raphjaph@protonmail.com> Co-authored-by: duttydeedz <142775511+duttydeedz@users.noreply.github.com> Co-authored-by: Casey Rodarmor <casey@rodarmor.com> Co-authored-by: liam <31192478+terror@users.noreply.github.com> Co-authored-by: Eloc <42568538+elocremarc@users.noreply.github.com> Co-authored-by: Julian Eager <eagr@tutanota.com> Co-authored-by: ordinally <11798624+veryordinally@users.noreply.github.com> Co-authored-by: Christopher Berner <me@cberner.com> Co-authored-by: Rijndael <115941166+rot13maxi@users.noreply.github.com> Co-authored-by: vuittont60 <81072379+vuittont60@users.noreply.github.com>
* Fix lost sats bug (ordinals#2666) * Add Hindi version of handbook (ordinals#2648) * Remove Index::index_block_inscription_numbers (ordinals#2667) * Hide protocol inscriptions (ordinals#2674) * Don't color links in headers (ordinals#2678) * Add inscription charms (ordinals#2681) * Group rune server tests (ordinals#2685) * Add inscription compression (ordinals#1713) * Fix media table formatting (ordinals#2686) * Update schema version for charms (ordinals#2687) * Fix unbound outpoint server error (ordinals#2479) * Add binary media type (ordinals#2671) * Clean up install.sh (ordinals#2669) * Add /collections Page (ordinals#2561) * Preview font inscriptions (ordinals#2692) * Only load used language highlight module in code preview (ordinals#2696) * Only try to create the database if it wasn't found (ordinals#2703) * Move postage into batch file (ordinals#2705) * Add destination field to batch (ordinals#2701) * Use sequence numbers database keys (ordinals#2664) * Update redb to 1.4.0 (ordinals#2714) * Refactor inscriptions paginations (ordinals#2715) * Display table stats in `ord index info` (ordinals#2711) * Use redb's recovery callback API (ordinals#2584) * Allow setting CSP origin (ordinals#2708) * Remove default file path from `ord index export --tsv` (ordinals#2717) * Use icons in nav bar (ordinals#2722) * Add Debian packaging instructions (ordinals#2725) * Add Homebrew install instructions to readme (ordinals#2726) * Add sat recursive endpoints with index and pagination (ordinals#2680) * Only accept sat number in recursive endpoint (ordinals#2732) * Fix typo in docs/src/inscriptions/metadata.md (ordinals#2731) * Add docs for metadata recursive endpoint (ordinals#2734) * Remove `RUNE` from <h1> on /rune (ordinals#2728) * Add /r/children recursive endpoint (ordinals#2431) * Add docs and examples for sat recursive endpoint (ordinals#2735) * Ignore flaky test (ordinals#2742) * Update docs to include all fields, including content-encoding (ordinals#2740) * Add docs for child recursive endpoint (ordinals#2743) * Hide JSON and .btc (ordinals#2744) * Release 0.12.0 (ordinals#2746) * Hide all text (ordinals#2753) * Add batch to preview command (ordinals#2752) * Add stuttering curse (ordinals#2745) * Batch inscribe on same sat (ordinals#2749) * Allow setting the sat to inscribe (ordinals#2765) * Select further away coins which meet target (ordinals#2724) * Fix typos (ordinals#2768) * Add ability to specify sat to batch inscribe (ordinals#2770) * Add commands to etch and list runes (ordinals#2544) * Set CSP origin in deploy script (ordinals#2764) Co-authored-by: raph <raphjaph@protonmail.com> * Add `public` to /content Cache-Control headers (ordinals#2773) * Release 0.12.1 (ordinals#2776) * Bless cursed inscriptions after Jubilee height (ordinals#2656) * Hide /content/<INSCRIPTION_ID> HTML inscriptions (ordinals#2778) * Release 0.12.2 (ordinals#2780) * fix(test): error test from version 0.12.2 --------- Co-authored-by: raph <raphjaph@protonmail.com> Co-authored-by: duttydeedz <142775511+duttydeedz@users.noreply.github.com> Co-authored-by: Casey Rodarmor <casey@rodarmor.com> Co-authored-by: liam <31192478+terror@users.noreply.github.com> Co-authored-by: Eloc <42568538+elocremarc@users.noreply.github.com> Co-authored-by: Julian Eager <eagr@tutanota.com> Co-authored-by: ordinally <11798624+veryordinally@users.noreply.github.com> Co-authored-by: Christopher Berner <me@cberner.com> Co-authored-by: Rijndael <115941166+rot13maxi@users.noreply.github.com> Co-authored-by: vuittont60 <81072379+vuittont60@users.noreply.github.com> Co-authored-by: gmart7t2 <49558347+gmart7t2@users.noreply.github.com> Co-authored-by: xiaolou86 <20718693+xiaolou86@users.noreply.github.com>
Fixes #2659.