In reply to

n@neeg:nitro.chat
Is there any protection from DNS hijacking in bsky/atproto?

https://atproto.com/

https://github.com/bluesky-social/atproto

Which one is the preferred?

• atproto (repo name)
• ATProto (idk if this is written)
• ATProtocol (logo)
• AT Protocol (in docs)

The amount of data shared is "crazy". And offers possibilities in a way we haven't seen before. A lot of those have been so far only available for the service(=Twitter, Facebook,...); but they are problematic, that's why the GDPR limits those possibilities. They aren't allowed to use the data for whatever purpose they want, they aren't even allowed to collect some of the data. Like they aren't allowed to use a mobile number which was given for 2fa, they can't just use to inform you about a new product. And some data may not be collected at all, if there is no good reason to collect it.

I'm not a lawyer so I'm only speaking from my amateur point of view: the first issue already is: whoever wants to do "evil" doesn't even need to store data anymore (so all parts of GDPR regarding storage is circumvented), they can simply access them on demand. The access is easier than ever before - you can download literally just everything of a user by requesting their whole repo. With dids this isn't even anymore limited to a "username" it'll be often the whole history of a person, following even dozens of username changes (also nice: you can already check which other handles someone used - a lot of this information will give deeper information into external user databases, like "oh, we have also two such users, which we thought were two different individuals - look at those, they really made a new account because... some reason"). The user gave this information to this social media, without understanding what they do possible to totally different areas of their life.

The bigger issue though is - I have doubts, that any "evil entity" even does anything illegal. The data is offered publicly. It's most likely offered for federation, but can the data abuser know that it wasn't offered for whatever purposes - can anyone proof them any knowingly wrong doing? They never even had to pretend to use it for anything else than "evil". If someone goes to town center and yells their secrets for everyone to hear, it is okay for everyone who can hear it to know it. There was no illegal action in obtaining the information. But if the information is accessible on demand and doesn't need to be stored, they don't have to fear being caught anyway. Amazon could access your repo and adjust their advertising based on your repo data. On demand, on the fly. Without the need for cookies, without having anything about you stored, and without you knowing. Yes, they need to know your did - hopefully you have a custom handle and it's a match (

And it's still early, with the first tools appearing. I guess it's by far not even the top of the iceberg, leave alone the massive threat lurking in the dark waters. Crazier tools will appear, with possibilities I likely even haven't though of yet. Labels might make it a lot easier/faster/more efficient to access already somewhat preprocessed data. Yes it's all beta and some things hopefully will get more restricted, but I think we also don't know yet the possibilities.

But to me it looks (right now) like the wet dream of any data collector/ processor (regarding laws, but also the collection, storing gets so much cheaper as it'll done by others), and a nightmare/ruin for pds servers (if GDPR makes the pds service liable) or a complete sellout of your private data in a way one hasn't even imagined. I personally don't mind any of the content I post to be known by anyone (or I wouldnt post it in the first place) but most average users aren't aware of what they are doing. And even I slowly start to feel uncomfortable (like the handle history is something I haven't thought of).

My interest in bluesky/atproto is not only for private use but business purposes, too. For the later it seems right now too "dangerous" to me (although likely highly lucrative).

GDPR is quite strict what you may do. Things which seem maybe pretty harmless can get heavy fines. One can argue who exactly would get burned (the data abusers are possibly safe here, but again, ianal), but someone will get burned, I would guess (probably the pds instances as they were the once who shared the data, without their users being fully aware of how the data could be used). And even if not - then the loss in trust by the users, which would happen eventually, might cost as much.

Like in the former message: this is my view right now. Things still change, as the information about atproto/bsky changes. Next month it might be completely different.

I really appreciate you bringing this up, because I had this concern a while back and completely forgot about it. it certainly does seem like if indexers' and PDSs' data are fully public that companies could profit off the the public data without ever having to worry about GDPR concerns, while users are left out to dry.

it's also a good question about whether PDSs themselves would be liable for being "irresponsible" with people's data by just letting it be public (even by design, even with people's permission). I think the law just hasn't caught up yet to this kind of tech and really needs to.

It may be better to frame the question as How will bluesky support verifiable credentials?

Verification of control of a domain name is different than an email address is different than verified employee of an organization is different than verified age.

@chrislace Broader extra credit much reading:

https://www.w3.org/TR/did-core/

It is worth noting the distinction between a handle and a DID.
Let's take the example of @

When I search for @

1_atproto.whitehouse.gov. IN TXT "did=did:plc:fivojrvylkim4nuo3pfqcf3k" 

but when I click follow the DID uri is the string that is added to my follow list.
When I @mention the handle string will appear in the text of the post but the DID uri will appear in the metadata on the post.
Even once the domain moves to the next president the link in your post will still go to the controller of the DID not the controller of the DNS name. Someone that looks at your follows will see you as following the DID not the DNS name.

The handle is basically a fancy search that you used to find a DID at a moment in time. Also when you localy do a search after the transfer you should get a result that looks like a disambiguation page with the @

This is analogues to what happens to the https://twitter.com/potus twitter handle when there is a new potus the old handle is renamed to https://twitter.com/potus45 and a new account with a new UserID is renamed to https://twitter.com/potus all the old follows and mentions stay linked to @potus45 => 822215679726100480 and the new mentions point to @potus => 1349149096909668363 if you follow https://twitter.com/potus today you will find you are folowwing @potus46 => 1349149096909668363 at some point in the future.

In reply to

moved to @shreyan:beeper.com (@shreyanjain:matrix.org)
the reason they are limiting invites right now is because it is a beta. things are not ready for the general public yet. they need a smaller subset of people to test and give feedback before releasing it to the general public

Hii, I am struggling a bit getting @atproto/api (https://socket.dev/npm/package/@atproto/api) to work on an expo iOS client. Everything is working perfectly on the web but for some reason, the login function fails when running Expo on iOS (npx expo start --ios).

await agent.login({ identifier: email, password });

The code snippet above returns the error function is undefined, specifically, it tries to use a function in URL.js

ERROR [TypeError: undefined is not a function]

I attached a screenshot of the error below. Does anyone know what I can do?

I’m an app developer and I want to create an AppView with a custom algorithm choice.

I’ve been lurking here for a bit, and I’ve read all the blog entries at

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758require "secp256k1"
require "big"
require "http/client"
require "json"

key= Secp256k1::Key.new
B58BT= "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"

class Array(T)
  def to_base58
    r= ""
    n= BigInt.new 0
    self.each do |byte|
      n= n*256+byte
    end
    loop do
      r+= B58BT[n%58]
      n= n//58
      break if n==0
    end
    r.reverse
  end
end

class Secp256k1::Key
  def public_did
    "did:key:z#{(Bytes[0xe7, 0x1].to_a + public_bytes_compressed.to_a).to_base58}"
  end
end

did= key.public_did
fn= "#{did.split(':')[-1]}.key"
File.write fn, key.private_hex

puts "Stored the private key for '#{did}' as a hexstring in #{fn}.\nKeep it safe and secure!"
print "On which server do you want to register (just press Enter if you're clueless what that means)? "
host= (gets||"").chomp
print "What's your email? "
email= (gets||"").chomp
print "What handle do you want? "
handle= (gets||"").chomp
print "What password do you want to use? "
password= (gets||"").chomp
print "And finally: What's your invite code? "
inviteCode= (gets||"").chomp

host= "https://bsky.social" if host.empty?
host= "https://#{host}" unless host.starts_with? "http"
resBody= HTTP::Client.post("#{host}/xrpc/com.atproto.server.createAccount", 
                              headers: HTTP::Headers{"User-Agent" => "accountCreator0.1", "Content-Type" => "application/json"}, 
                              body: "{\"handle\":#{handle.inspect},\"password\":#{password.inspect},\"email\":#{email.inspect},\"inviteCode\":#{inviteCode.inspect},\"recoveryKey\":#{did.inspect}}").body
jres= JSON.parse resBody
if (error= jres["error"]?)
  puts "Couldn't create the account, because… #{jres["error"]}: #{jres["message"]?||"???"}"
  puts "The key has not been removed, in case account creation was somehow successful - but that's unlikely :("
else
  puts "Hooray! All good. Now go and have fun!"
end  

It's not perfect, but it should give everyone an idea, how it works (and while not perfect, it works, it just could do the one or the other thing probably a bit better)