IRC log of dig on 2013-03-29
Timestamps are in UTC.
- 00:48:07 [rszeno]
- rszeno has quit (Quit: Leaving.)
- 02:23:39 [scor]
- scor (~scor@c-98-216-39-127.hsd1.ma.comcast.net) has joined #dig
- 02:23:39 [scor]
- scor has quit (Changing host)
- 02:23:40 [scor]
- scor (~scor@drupal.org/user/52142/view) has joined #dig
- 02:56:45 [scor]
- scor has quit (Quit: scor)
- 05:53:35 [bblfish]
- bblfish (~bblfish@AAubervilliers-651-1-301-37.w83-114.abo.wanadoo.fr) has joined #dig
- 07:50:32 [melvster]
- melvster (~melvin@89.176.108.70) has joined #dig
- 08:11:45 [melvster]
- melvster has quit (Ping timeout: 255 seconds)
- 08:12:52 [trueg_away]
- trueg_away is now known as trueg
- 08:18:58 [melvster]
- melvster (~melvin@ip-94-112-34-93.net.upcbroadband.cz) has joined #dig
- 09:42:56 [jmvanel]
- jmvanel has quit (Ping timeout: 260 seconds)
- 10:04:28 [rszeno]
- rszeno (~rszeno@79.114.105.37) has joined #dig
- 10:15:29 [melvster]
- hi bblfish: may be faster to discuss cert : key on irc rather than mail?
- 10:15:54 [bblfish]
- could be.
- 10:16:17 [bblfish]
- not sure. I'd rather not change cert:key relation I have a bad feeling about it.
- 10:16:38 [melvster]
- do you really think a change in the ontology would then trigger multiple changes elsewhere? is this to do with reasoning or IFP etc.?
- 10:16:50 [melvster]
- sure i just want to try and understand the logic
- 10:17:23 [melvster]
- it would be nice if the cert ontology could be used in payment too, otherwise we have to write another almost identical ontology one for agents one for payments
- 10:17:38 [bblfish]
- who says it cannot be used in payments?
- 10:18:01 [melvster]
- payments work with accounts, rather than agents
- 10:18:05 [melvster]
- agents have an account
- 10:18:11 [melvster]
- it's pretty confusing
- 10:18:21 [bblfish]
- do the bitcoin people have an ontology or are you just making it up?
- 10:18:24 [melvster]
- but basically that's how accountancy has worked for a longtime
- 10:19:06 [melvster]
- they use dsa keys tied to an account
- 10:19:16 [melvster]
- so the foaf and cert ontologies can be reused
- 10:19:16 [bblfish]
- have they got an ontology?
- 10:19:21 [melvster]
- and also the label
- 10:19:37 [melvster]
- im unsure who you mean by 'they'
- 10:19:43 [bblfish]
- the bitcoing people
- 10:19:51 [melvster]
- sure
- 10:19:56 [bblfish]
- where?
- 10:19:59 [melvster]
- multiple
- 10:20:01 [melvster]
- foaf isone
- 10:20:05 [bblfish]
- which is the official one?
- 10:20:06 [melvster]
- dcterms
- 10:20:30 [bblfish]
- where is the official bitcoin ontology spec that we can refer to to see what their problem is?
- 10:20:51 [melvster]
- let's forget bitcoin for the moment
- 10:20:58 [melvster]
- i think that's distracted the conversation
- 10:21:23 [bblfish]
- ok. So you want to just use the bucket analogy
- 10:21:34 [bblfish]
- you have a bank account and the bank account is a bucket
- 10:21:34 [melvster]
- sure ... bucket would be like an account
- 10:21:38 [melvster]
- exactly!
- 10:21:58 [melvster]
- now associated with this bucket would be a key
- 10:22:03 [bblfish]
- A bank account may even be like an ldp:Container
- 10:22:05 [melvster]
- much like assoicated with a safe is a key
- 10:22:16 [bblfish]
- you can POST new moeny to it, and you can remove money from it
- 10:22:43 [melvster]
- im unsure LDP can model distributed buckets very well
- 10:22:57 [melvster]
- because the problem bitcoin solves is a race condition known as 'double spend'
- 10:23:04 [bblfish]
- ah you are back to bitcoin
- 10:23:12 [melvster]
- yes
- 10:23:20 [melvster]
- but you can think of it as distrubted buckets
- 10:23:20 [bblfish]
- but you said above it confuses things
- 10:23:30 [melvster]
- i can generalize
- 10:23:54 [melvster]
- in the situation of a distributed bucket system
- 10:24:15 [bblfish]
- you mean you have a bucket and I have a bucket.
- 10:24:15 [melvster]
- you need to be able to increment and decrement buckets
- 10:24:23 [melvster]
- ok good example
- 10:24:27 [melvster]
- but it extends to N buckets
- 10:24:35 [bblfish]
- timbl has a bucket
- 10:24:41 [melvster]
- for example
- 10:24:53 [melvster]
- now in a decentralized environment
- 10:24:55 [bblfish]
- ok. So you can put money into my bucket but not remove it.
- 10:25:01 [melvster]
- it's a hard problem to determine what is in every bucket
- 10:25:24 [bblfish]
- look I don't have 20hours to discuss this.
- 10:25:41 [melvster]
- ill try and be succinct
- 10:25:43 [bblfish]
- The thing is you can see that you are going way into hypotheticals here.
- 10:26:10 [melvster]
- but the summary is that accounts need to be able to have keys (independent of bitcoin, webid etc.)
- 10:26:20 [bblfish]
- I don't think you'll have the resources to explain why you need cert:key's domain to be rdfs:Resource
- 10:26:38 [bblfish]
- you mean public keys?
- 10:26:46 [webr3]
- webr3 has quit (Ping timeout: 246 seconds)
- 10:26:47 [melvster]
- pub/priv key pairs
- 10:27:02 [melvster]
- but keys
- 10:27:10 [bblfish]
- ok. Who operates the private key?
- 10:27:11 [melvster]
- i didnt say public keys, i said keys
- 10:27:20 [bblfish]
- the bucket itself?
- 10:27:23 [melvster]
- out of scope
- 10:27:27 [bblfish]
- no
- 10:27:30 [melvster]
- it's just a key associated with a bucket
- 10:27:38 [bblfish]
- the cert:key relates the owner of the private key to the public key
- 10:27:45 [bblfish]
- so why not create a new relation
- 10:28:00 [melvster]
- sure i could fork the whole ontology
- 10:28:06 [bblfish]
- bucket wac:accessibleBy key
- 10:28:15 [bblfish]
- no you don't have to fork the whole ontology
- 10:28:20 [bblfish]
- you just need one new relation
- 10:28:59 [melvster]
- i think we essentially have 2 concepts here:
- 10:29:10 [melvster]
- 1) a WebID public key
- 10:29:14 [melvster]
- 2) a public key
- 10:29:35 [bblfish]
- cert:key relates an agent to a key.
- 10:29:45 [bblfish]
- you can then create a relation to relate a bucket to a key
- 10:29:46 [melvster]
- yes my point is that that is a bug
- 10:29:54 [bblfish]
- why not a new relation?
- 10:30:06 [melvster]
- a new relation in the cert ontology?
- 10:30:11 [melvster]
- that could work
- 10:30:16 [bblfish]
- or another ontology
- 10:30:22 [bblfish]
- the bitbucket ontology
- 10:30:30 [melvster]
- it's generally good practice to reuse stuff tho
- 10:30:59 [melvster]
- otherwise there's double to maintain and double to implement
- 10:31:16 [bblfish]
- yes, but if you can't re-use it then you create a new relation. We have one in WAC. The realtion between an ACL and agents, resource, and methods
- 10:31:48 [melvster]
- im only interested in publickey at this point, not in WAC, agents, TLS or anything else
- 10:32:16 [bblfish]
- you mention bitbucket. And we don't know what the best way to model their use case is
- 10:32:17 [webr3]
- webr3 (~nathan@host213-122-100-71.range213-122.btcentralplus.com) has joined #dig
- 10:32:26 [melvster]
- it didnt mention bitbucket, you did
- 10:32:49 [melvster]
- oh, you mean bitcoin?
- 10:33:03 [melvster]
- ok let me quickly describe that
- 10:33:23 [melvster]
- a bitcoin account is a foaf : OnlineAccount with a label, and a DSA key pair
- 10:33:29 [bblfish]
- http://lists.w3.org/Archives/Public/public-webid/2013Mar/0074.html
- 10:33:34 [bblfish]
- I meant bitcoin sorry
- 10:33:53 [melvster]
- ah ok
- 10:34:07 [bblfish]
- where is that specified?
- 10:34:11 [melvster]
- one sec
- 10:37:47 [melvster]
- e.g. http://en.wikipedia.org/wiki/Bitcoin#Addresses there's lots of info in the bitcoin wiki about the exact details ...
- 10:38:12 [melvster]
- btw bitcion is completely decentralized
- 10:38:16 [melvster]
- so there's not really a 'they
- 10:38:23 [melvster]
- it's not a corporation or w3c member etc
- 10:38:28 [melvster]
- it's a technology like git or the web
- 10:38:57 [bblfish]
- That is not an ontology. There is no mention of foaf:Account there.
- 10:38:59 [melvster]
- but it's the biggest distributed computing project on the planet now
- 10:39:11 [rszeno]
- melvster, imo you need to build a specific ontology for bitcoin
- 10:39:28 [bblfish]
- yes, but you are assuming that they need a relation between an account and a key. They may not need that.
- 10:39:45 [bblfish]
- they may be ok with a WebID relation to an key.
- 10:39:47 [melvster]
- yes that's my assumption
- 10:39:54 [bblfish]
- but it may be flawed
- 10:39:57 [melvster]
- it may
- 10:40:15 [melvster]
- however, it has lead me to uncover what i think is a bug in the cert ontology
- 10:40:28 [melvster]
- two separate conversations, in a way
- 10:40:36 [bblfish]
- it can't be a bug until it is clear that your ontology is a good one
- 10:40:42 [bblfish]
- and you have no ontology
- 10:40:55 [melvster]
- sure it can
- 10:41:03 [melvster]
- bugs are not dependent on external ontologies
- 10:41:42 [melvster]
- the question lies as to A) what should be the domain of cert : key B) what is the cost of changing
- 10:42:00 [bblfish]
- you are saying: I think one could model X this way, if it is modelled this way then you have a bug. But you have not proven that your way of modelling it is correct. So it is only a hypothetical bug. How can we fix hypothetical bugs
- 10:42:38 [melvster]
- you examine the semantics
- 10:42:39 [bblfish]
- ?
- 10:42:57 [bblfish]
- You have no semantics yet. You have a hypothetical semantics
- 10:43:05 [melvster]
- the :key relation has a Domain
- 10:43:09 [bblfish]
- yes.
- 10:43:59 [bblfish]
- it has foaf:Agent as a domain
- 10:43:59 [melvster]
- that is the possibility space of who can have a Key
- 10:44:27 [bblfish]
- no it defines the cert:key relation
- 10:44:27 [trueg]
- trueg is now known as trueg_away
- 10:44:27 [bblfish]
- you want to define access control to bitcoin "buckets". It may be that an access control ontology is the way to go.
- 10:44:37 [bblfish]
- that is what WAC does.
- 10:45:22 [melvster]
- question
- 10:45:25 [bblfish]
- in your logic we could have argued that resources require access to people who can prove keys. So perhaps you would want to say <> putAccess key .
- 10:45:30 [melvster]
- is a bank account an Agent?
- 10:45:52 [bblfish]
- not if you think of it as a bucket.
- 10:46:04 [bblfish]
- where you can put money in
- 10:46:10 [melvster]
- yet a bank account could be protected with PKI
- 10:46:15 [bblfish]
- yes.
- 10:46:16 [melvster]
- it could have public and private keys
- 10:46:20 [bblfish]
- no
- 10:46:28 [bblfish]
- you can model it with WAC
- 10:46:52 [bblfish]
- with WAC you can say this agent can PUT money into the bucket, and this one can GET money out of it
- 10:47:25 [melvster]
- ok well it may not be an efficient use of time to explain how modern accountancy works ... could we quickly just talk about ( B) what would be the implications of changing Agent to Resource
- 10:47:56 [melvster]
- 1. why would it be impossible leave implementations untouched
- 10:47:58 [bblfish]
- I don't think there is much about accountance relevant to this problem that I don't understand
- 10:48:20 [bblfish]
- that is the question you asked in the e-mail
- 10:48:22 [melvster]
- 2. why would it be impossible to leave other specs untouched
- 10:48:24 [melvster]
- yes
- 10:48:35 [bblfish]
- so you see the chat on irc did not get us further.
- 10:48:57 [melvster]
- i dont see that
- 10:49:03 [bblfish]
- the quesiton I have is why do we need to extend the range of cert:key
- 10:49:07 [melvster]
- but you are entitled to think so
- 10:49:11 [melvster]
- ok
- 10:49:17 [melvster]
- that i can explain
- 10:49:52 [bblfish]
- well above you said you have a hypothetical case,
- 10:50:01 [bblfish]
- and that is not a good or solid argument
- 10:50:11 [melvster]
- i would like to start 'webizing' mature distributed computing problems in the payments space, but not limited to that, it extends to all robots that will be able to use digital or legacy cash
- 10:50:25 [bblfish]
- because I can show that we can do access control to resources in a fine grained manner without your extension
- 10:50:31 [melvster]
- for this, i would like to model PKI pub/pri key pairs
- 10:50:46 [bblfish]
- ok you can use the cert ontology for that
- 10:51:46 [melvster]
- id like to reuse cert ontology
- 10:52:16 [bblfish]
- ( anyway it's good to know that bitcoin uses DSA - in fact they use ECDSA - which is eliptic curve DSA - which I am not sure is related directly to DSA btw )
- 10:52:27 [bblfish]
- who says you cannot?
- 10:52:29 [melvster]
- so for example an agent could have multiple accounts, each with a key/pair, all capable of payments
- 10:53:07 [bblfish]
- why do you think that the bitcoin should be modelled as an foaf:Account?
- 10:53:12 [cheater__]
- cheater__ (~cheater@p57AEB110.dip.t-dialin.net) has joined #dig
- 11:14:24 [DIGlogger]
- DIGlogger (~dig-logge@groups.csail.mit.edu) has joined #dig
- 11:14:24 [adams.freenode.net]
- topic is: Decentralized Information Group @ MIT http://dig.csail.mit.edu/
- 11:14:24 [adams.freenode.net]
- Users on #dig: DIGlogger RalphS cheater__ webr3 rszeno melvster bblfish bergi trueg_away betehess Yudai___ sandro_ ericP_ presbrey tyteen4a03 manu1 manu-db mattl
- 11:15:03 [melvster]
- a file can have a public key
- 11:15:08 [melvster]
- but the agent can use that key
- 11:16:27 [melvster]
- i think you're suggesting having something like cert : hasKey to have a wider domain, but to my mind it seems more logical just to let cert : key do that job, you've not explained why WAC needs changing
- 11:16:36 [bblfish]
- DigLogger: the logs you missed are here: http://pastebin.com/DwfXaRMh
- 11:16:36 [bblfish]
- I'm logging. I don't understand 'the logs you missed are here: http://pastebin.com/DwfXaRMh', bblfish. Try /msg DIGlogger help
- 11:17:04 [bblfish]
- melvester why do you put spaces between the prefix and the name?
- 11:17:17 [bblfish]
- cert : hasKey instead of cert:hasKey ?
- 11:17:19 [melvster]
- because in some client is turns into a smiley
- 11:17:23 [melvster]
- on IRC
- 11:17:30 [melvster]
- :P
- 11:17:36 [melvster]
- is : P
- 11:17:47 [melvster]
- so :PublicKey is a smiley for me
- 11:17:53 [melvster]
- is less readable
- 11:18:01 [bblfish]
- ah, you should turn off smileys
- 11:18:14 [melvster]
- sure but i cant turn off smiley's for everyone
- 11:18:50 [bblfish]
- melvster if you have cert:key have a domain of anything, then we start having to explain what the relation of that anything is to the private key of the public key
- 11:19:06 [bblfish]
- is there an owner of that anything that has control of the private key?
- 11:19:30 [melvster]
- in webid sure there is, nothing changes there
- 11:19:34 [bblfish]
- so now we need two relations. The relation of ownership to an anything, that may have a cert key.
- 11:19:59 [melvster]
- a webid is already an agent
- 11:20:07 [trueg_away]
- trueg_away is now known as trueg
- 11:20:29 [melvster]
- im NOT suggesting change what a webid is
- 11:20:35 [melvster]
- that stays exactly the same
- 11:20:43 [bblfish]
- ok, so now we need to always check that a thing is a foaf:Agent too.
- 11:20:55 [bblfish]
- so we need to do twice the work
- 11:21:36 [bblfish]
- because your cert:key relation is something has a relation to a key. What is that relation? Where is the agent that has the private key?
- 11:22:21 [melvster]
- wait, remember what a key is, its just a number
- 11:22:22 [bblfish]
- you need to get the triangle of the private key in there.
- 11:22:28 [bblfish]
- exactly
- 11:22:40 [bblfish]
- so cannot everything have a cert:key relation to my key?
- 11:23:27 [melvster]
- i think this is what Mo meant when he said rdf : Resource ... btw we could ask him on #swig he is nevali there
- 11:24:22 [bblfish]
- rdf:Resource means anything.
- 11:24:26 [melvster]
- ok
- 11:24:36 [melvster]
- so it means we dont restrict it
- 11:25:43 [bblfish]
- yes
- 11:26:16 [bblfish]
- which means that in those cases where it is an agent, the relation between the public key and the private key gets lost
- 11:27:00 [melvster]
- do you mean "the relation between the public key and the private key"
- 11:27:12 [melvster]
- or "the relation between the resource and the public key"
- 11:28:06 [melvster]
- so instead of having
- 11:28:09 [melvster]
- agent -> key
- 11:28:11 [melvster]
- we have
- 11:28:16 [melvster]
- agent -> key
- 11:28:17 [melvster]
- AND
- 11:28:21 [melvster]
- resource -> key
- 11:28:22 [melvster]
- and
- 11:28:29 [melvster]
- agent -> resource -> key
- 11:28:40 [melvster]
- in particular, it's useful when that resource is an account
- 11:28:56 [bblfish]
- it seems useful, but it is bad modelling.
- 11:29:11 [bblfish]
- it won't work.
- 11:29:34 [melvster]
- why?
- 11:29:59 [melvster]
- webid will still work
- 11:30:02 [melvster]
- wac will still work
- 11:30:09 [melvster]
- implementations will still work
- 11:30:17 [melvster]
- and you get more for free
- 11:30:58 [melvster]
- a key is just a number
- 11:31:09 [melvster]
- it seems odd to say that only an agent can have a number
- 11:31:26 [melvster]
- and you rule out whole classes of things such as bank accounts
- 11:31:45 [bblfish]
- you don't rule anything out at all
- 11:31:55 [bblfish]
- you just model it differently
- 11:32:23 [melvster]
- i mean in terms of using the natural turn which is in the cert ontology of ": key"
- 11:32:52 [melvster]
- one way to model it would be
- 11:33:01 [melvster]
- like we used to have cert : identity
- 11:33:07 [melvster]
- we could have cert : account
- 11:33:08 [melvster]
- but
- 11:33:26 [melvster]
- after long discussions people felt it was more natural to go the other direction
- 11:37:23 [melvster]
- reusing : key i can start building webid bots with payment ability today
- 11:37:46 [trueg]
- trueg is now known as trueg_away
- 11:37:47 [melvster]
- maybe i should just do that and we can change the ontology later
- 11:37:54 [melvster]
- if at all
- 11:38:21 [melvster]
- showing a useful implementation always is a good argument towards consensus
- 11:38:29 [melvster]
- then it's less hypothetical
- 11:43:12 [trueg_away]
- trueg_away is now known as trueg
- 11:47:33 [bblfish]
- not just an implementation, an ontology.
- 11:47:41 [bblfish]
- and you need to have it reviewed.
- 11:49:39 [melvster]
- bblfish: what's the way forward, should we continue on IRC / on email / or should I raise an issue? I still claim you have not made any reasonable objections that I can understand ...
- 11:49:57 [melvster]
- i claim it's abug
- 11:49:57 [bblfish]
- I am trying to respond to your mail.
- 11:50:01 [melvster]
- ok sure
- 11:50:09 [melvster]
- and one that's easy to fix
- 11:50:23 [bblfish]
- no it is not easy to fix
- 11:50:26 [bblfish]
- there is no bug.
- 11:50:36 [bblfish]
- your improvement in fact introduces bugs
- 11:50:45 [bblfish]
- so I am trying to argue that.
- 11:52:42 [melvster]
- ok well i guess the WG will decide in time ... im just trying to understand better
- 11:53:58 [melvster]
- so far two are in favour rdfs : Resource one is in favour of foaf : Agent
- 11:54:36 [melvster]
- that expressed opinions on the thread
- 11:55:20 [melvster]
- one way to model it
- 11:55:31 [melvster]
- i could say bitcoin:1d8ds8hdioahihd is an Agent
- 11:55:36 [melvster]
- what's an agent?
- 11:55:42 [melvster]
- "things that do stuff"
- 11:56:01 [melvster]
- then the agent has the key
- 11:56:07 [melvster]
- tho is NOT a webid
- 11:56:11 [melvster]
- officially
- 11:56:34 [melvster]
- can an account be an agent i wonder
- 12:00:04 [scor]
- scor (scor@nat/acquia/x-vegtuyulblmhxewj) has joined #dig
- 12:00:04 [scor]
- scor has quit (Changing host)
- 12:00:04 [scor]
- scor (scor@drupal.org/user/52142/view) has joined #dig
- 12:07:23 [trueg]
- trueg is now known as trueg_away
- 12:52:50 [melvster]
- bblfish: im not sure the Range of cert : key should not be cert : PublicKey either -- see the description, "key - relates an agent to a key - most often the public key. "
- 13:12:29 [bblfish]
- yes, I would be ok with that change.
- 13:12:35 [trueg_away]
- trueg_away is now known as trueg
- 13:12:56 [bblfish]
- it would require a relation privateKey from public to private key
- 13:14:32 [bblfish]
- here is the answer I was thinking of above http://lists.w3.org/Archives/Public/public-webid/2013Mar/0083.html
- 13:15:03 [bblfish]
- and here is the second answer http://lists.w3.org/Archives/Public/public-webid/2013Mar/0085.html
- 13:53:03 [melvster]
- melvster has quit (Ping timeout: 260 seconds)
- 13:55:23 [melvster]
- melvster (~melvin@ip-94-112-34-93.net.upcbroadband.cz) has joined #dig
- 14:15:46 [jmvanel]
- jmvanel (~jmvanel@139.239.24.109.rev.sfr.net) has joined #dig
- 14:25:46 [timbl]
- timbl (~timbl@30-5-66.wireless.csail.mit.edu) has joined #dig
- 14:37:07 [scor]
- scor has quit (Ping timeout: 264 seconds)
- 14:37:43 [scor]
- scor (scor@nat/acquia/x-fykeaanlhxsxzquc) has joined #dig
- 14:37:44 [scor]
- scor has quit (Changing host)
- 14:37:44 [scor]
- scor (scor@drupal.org/user/52142/view) has joined #dig
- 15:00:35 [timbl]
- timbl has quit (Quit: timbl)
- 15:04:39 [timbl]
- timbl (~timbl@30-5-66.wireless.csail.mit.edu) has joined #dig
- 15:07:54 [melvster]
- bblfish: you could just add both keys to the range if you want an easy solution (pub/pri)
- 15:08:38 [melvster]
- just reading your reply
- 15:35:41 [melvster]
- bblfish: i guess we have quite different views on the complexity of this, we can just let the CG or WG reach a consensus and hopefully make a quick change, as necessary
- 15:36:05 [melvster]
- if it stays agent, ill make a new predicate
- 15:36:16 [melvster]
- if it is resource, ill reuse
- 15:37:19 [melvster]
- it might make more sense just to start fresh, tho i thought it might be nice to see webid based robots making payments in the wild
- 15:38:45 [melvster]
- there's also: http://payswarm.com/specs/source/vocabs/security
- 15:38:52 [melvster]
- which is designed for payments
- 15:49:50 [trueg]
- trueg is now known as trueg_away
- 15:54:52 [trueg_away]
- trueg_away is now known as trueg
- 16:04:44 [timbl]
- timbl has quit (Quit: timbl)
- 16:18:06 [timbl]
- timbl (~timbl@30-5-66.wireless.csail.mit.edu) has joined #dig
- 16:27:30 [scor]
- scor has quit (Quit: scor)
- 17:14:01 [scor]
- scor (scor@drupal.org/user/52142/view) has joined #dig
- 17:27:43 [jmvanel]
- jmvanel has quit (Ping timeout: 260 seconds)
- 17:36:39 [melvster]
- melvster has quit (Quit: Leaving.)
- 17:40:41 [cheater_1]
- cheater_1 (~cheater@p57AEAF15.dip.t-dialin.net) has joined #dig
- 17:42:55 [trueg]
- trueg is now known as trueg_away
- 17:44:04 [cheater__]
- cheater__ has quit (Ping timeout: 260 seconds)
- 19:13:58 [jmvanel]
- jmvanel (~jmvanel@188.197.139.88.rev.sfr.net) has joined #dig
- 20:05:19 [ericP_]
- ericP_ is now known as ericP
- 20:05:49 [ericP]
- ericP is now known as Guest58435
- 20:18:37 [Guest58435]
- Guest58435 is now known as ericP
- 20:19:20 [RalphS]
- RalphS has quit ()
- 21:14:46 [scor]
- scor has quit (Quit: scor)
- 21:28:20 [trueg_away]
- trueg_away is now known as trueg
- 21:37:48 [timbl]
- timbl has quit (Quit: timbl)
- 21:46:54 [timbl]
- timbl (~timbl@30-5-66.wireless.csail.mit.edu) has joined #dig
- 21:50:29 [timbl]
- timbl has quit (Client Quit)
- 22:10:19 [trueg]
- trueg is now known as trueg_away
- 22:38:04 [jmvanel]
- jmvanel has quit (Ping timeout: 260 seconds)
- 22:45:03 [timbl]
- timbl (~timbl@c-24-62-225-11.hsd1.ma.comcast.net) has joined #dig
- 23:13:48 [betehess]
- betehess has quit (Quit: Leaving)
- 23:31:16 [melvster]
- melvster (~melvin@89.176.108.70) has joined #dig