J !OlcPsstCIA ID: 64b71c Baker ID system proposal June 26, 2018, 9:42 a.m. No.1435   🗄️.is 🔗kun   >>1437

Hello bakers, non-baker here,

 

Okay, so I've been reading baker posts, and it seems a lot of bakers support the idea of IDing themselves, however despite prodding BO appears to be ignoring the issue, so I figured I'd come here to discuss with you guys an alternative proposal on baker ID, although it depends on a number of assumptions.

 

Am I correct in assuming that on the Q research board, next to the name is a field labeled 'ID' (for example, mine was '9c1564'), which represents some sort of hashed copy of the person's IP address?

 

And am I correct in assuming you guys largely don't use proxies? Or, to put it more plainly, you use generally 'fairly' static IPs? By fairly static, I mean 'remains consistent for the duration of it's use' (EG 24 hours).

 

And would it be possible to get the same ID system enabled on this board?

 

The reason I'm mentioning this is I see a possible temporary 'workaround' that would allow a baker the reasonable ability to confirm their own authenticity.

 

So what I see is:

 

Comms has a baker 'sign-in' 'sign-out' thread (can be either separate or same thread).

 

Any time you come on duty or your IP changes, you 'sign-in' on the thread with your tripcode (along with an ID field populated with the hashed copy of your IP address).

 

Any time you leave duty, you 'sign-out' on the thread with your tripcode (along with the ID field populated with the hashed copy of the IP address).

 

When creating a bread, you reference the sign-in thread and say 'ID <whateversigned in!' - users can then go to the sign-in thread to verify that ID has been signed in.

 

This also allows bakers to see who is presently on or off-duty (this could be piggybacked with a dedicated 'request baker' thread in comms where a baker links to the thread requesting a hand-off).

 

It's admittedly crude, and subject to IP changes, but it means if you're signed out and a clown tries to impersonate you, there's a ledger to say 'oh hey, he's not presently signed in, that's a fraud'.

 

I suspect this method could be refined or improved, and seems inefficient to me, but without BO allowing tripcodes or a secret field or whatever I concur with bakers a system has to be devised.

 

Thoughts?