bnewbold.social.coop.ap.brid.gy
dweb, cycling, free software, snow, wiki, hardware, big cities, symbolic systems. I love speculating about found objects.
Working at https://blueskyweb.xyz/ on […]
[bridged from https://social.coop/@bnewbold on the fediverse by https://fed.brid.gy/ ]
58 posts
80 followers
6 following
Regular Contributor
Active Commenter
comment in response to
post
@jonny the tapes are individually cheap, but the read/write machines are expensive. that would be fine if the machines were reliable and/or compatible over long time periods, but they are not. they need repair, sometimes get more expensive second-hand, etc.
spinning disks, with integrated […]
comment in response to
post
@jonny my general impression is that tape storage doesn't make sense unless you are writing the data but don't actually intend to ever read it; or if somebody would pay you a bunch of money at the time of read. if you plan from the start to read the data back out of the system, even just once […]
comment in response to
post
@collectifission @anders.sorby.xyz if you are digging in to the scaling properties of atproto, check this out
https://github.com/bluesky-social/proposals/tree/main/0006-sync-iteration
comment in response to
post
@damonoutlaw.xyz (but a new/dedicated thing would be cool too!)
comment in response to
post
@damonoutlaw.xyz I think both IndieWeb and dweb are pretty good venues/communities for that sort of gathering?
comment in response to
post
@jsit it depends on the system; i'd be curious what Mastodon does, for example.
in the systems I am familiar with specifically for abusive images, things are not shown; black-and-white; and/or blurred by default. sometimes images are inverted or have other transforms to make them a bit "less […]
comment in response to
post
@strypey our current stance and thinking is that the lower levels of atproto fit better at the IETF: application-agnostic, authenticated transfer (transport) of data in a merkle-tree repository structure using CBOR, etc.
applicaiton-specific schemas on top of that layer are more "document" […]
comment in response to
post
we didn't pick DIDs because they have "decentralized" in the name, they are basically just an abstraction barrier to uncouple identity mechanisms.
PLC needs work, but is self-certifying and that keeps a lot of paths open.
comment in response to
post
this was pretty long so I didn't get in to DID / DNS stuff.
contact lists are awesome and under-utilized, and petnames are part of that. but they don't make sense for big-world or discovery.
we like DNS. it is technically centralized but power/governance is pretty devolved.
comment in response to
post
@paul @not2b yay!
comment in response to
post
@mho as a heads up, not sure how you are measuring traffic (Referer header? query params?), but tracking links from mobile apps specifically can be difficult. we have been looking in to this at Bluesky and will roll out some changes soon.
comment in response to
post
@wjmaggos this was not intention, and my understanding is that new content has been flowing. we had a serious incident on 2024-11-21 (last thursday) which has impacted some posts getting indexed from that day. we then had a clog catching up bridgyfed because of a misconfiguration.
we very much […]
comment in response to
post
@not2b @paul ... possible because we didn't have a UNIQUE constraint on a SQL table.
comment in response to
post
@not2b @paul just to clarify, we (I work for Bluesky) did not do anything intentional here. we had a broad service degradation on 2024-11-21 which impacted many services in the network, both those operated by us and others. We are still cleaning up impacted accounts.
I don't remember if we […]
comment in response to
post
@laurenshof I dug through some old notes and the closest I could find for this December milestone was:
> more complete threading
so presumably reply threads with participants on separate instances
comment in response to
post
@notplants @jonny
by default (and by design), labelers and feed generators work fine across any other infra like relays or appviews. labelers and feedgens reference DIDs and AT-URIs (global scope), and can be consumed/requested by any client.
that sort of assumes that all relays are "full […]
comment in response to
post
@glyph great post! I strongly agree with your framing and "best possible future"
comment in response to
post
@evan @mmasnick I would be more than happy to talk with folks from SWF or W3C if they share this specific concern about Bluesky exploiting patents on social web technology, and what we can do to allay those concerns.
The norm in this space is to participate in a standards body, and it remains […]
comment in response to
post
@evan @mmasnick when you raised patent concerns to me in person on March 2024, I took them very seriously! which is why I reached out and had a direct call with you about your concerns that same month.
"Right now, you're putting everyone in the space at risk" is a strong statement and […]
comment in response to
post
@evan @mmasnick Evan, as you and I have discussed directly in the past, all of the atproto specifications and core implementations are under free and open licenses. Specifically, MIT and Apache 2.0 dual-licensing, with Apache 2.0 providing patent protection. Furthermore, Patents have public […]
comment in response to
post
@blaine @liaizon @jonny the way AP/mastodon has played out is very different! I can't honestly say which strategy will have better outcomes in the long run. I am concerned that hosts like Facebook (Threads) will be able to exploit their users, and build network effects, and it will be hard for […]
comment in response to
post
@blaine @liaizon @jonny when we think about "what makes it easy to exploit and control", a lot of it comes down to difficulty of coordinating collective action, and network effects.
making it easy for people to "exit" individual hosts, while staying in the overall network (while retaining […]
comment in response to
post
@blaine @liaizon @jonny I think it is very fair and reasonable for folks to care about decentralization in material terms. eg, just a network/system by how large the largest node is: if any node is more than 50%, or 20%, or 5%, it isn't "really" decentralized.
that hasn't ever really been a […]
comment in response to
post
@blaine @liaizon @jonny you might know this, but the goal with atproto account portability is more akin to phone number portability than platform data "takeouts".
when an atproto account migrates, it isn't really apparent or visible. basically all the context and situation comes along. infra […]
comment in response to
post
@vitriolix there are a number of recent projects:
https://psky.social/
https://linkat.blue/
https://smokesignal.events/
https://whtwnd.com/
https://frontpage.fyi/
comment in response to
post
not sure how much it will help, but despite the word "blockchain" appearing in the blog post, want to re-iterate:
> This does not change the fact that the Bluesky app and the AT Protocol do not use blockchains or cryptocurrency, and we will not hyperfinancialize the social experience (through […]
comment in response to
post
@wake.st @bnewbold.net oh! sorry, forgot to link
https://www.youtube.com/watch?v=mrIGqsLy7K4
comment in response to
post
@wjmaggos it isn't exactly that, but I did this panel last year with Christine (AP standardization, now Spritely), Rabble (Twitter, then SSB, now nostr), Kegan (Matrix)
comment in response to
post
@wjmaggos to respond to your earlier request to have it be more obvious to opt-in in the bluesky-developed app: I think i'd probably encourage the bridge to just be opt-out on the AT side? we generally want to encourage projects like the bridge to be opt-out; having an opt-in flow in-app sets […]
comment in response to
post
@wjmaggos we got put on a number of AP-side instance blocklists before bridgy fed even existed, and the bridge has been controversial on many instances (including mine!). overall, kind of a spicy situation to wade in to aggressively.
we certainly support and encourage bridges, and interop and […]
comment in response to
post
@wjmaggos from a policy perspective (not official guidance), I think bsky would probably be fine having a bridge being opt-out vs opt-in, if responsibly done (as bridgy fed has been in general).
fedidb says about 36k AT -> AP accounts. our relay says about 25k AP -> AT accounts.
I'd be […]
comment in response to
post
@wjmaggos this is a pretty interesting request!
one of the big critiques of bsky/atproto is that it is too centralized / single-org. the bridge(s) being independent is nice in some ways, right?
I haven't done formal estimates, but my understanding is that AP is resource intensive at scale. it […]
comment in response to
post
ah! @arcanicanis
comment in response to
post
@thisismissem take care, hope you get well soon!