mirror of
https://github.com/sonr-io/sonr.git
synced 2026-08-03 01:41:44 +00:00
Merge branch 'feature/1232-create-vault-settings' into feature/1220-origin-handle-exists-method
This commit is contained in:
Prad Nukala
@@ -1,105 +0,0 @@
|
||||
You are an expert in Cosmos SDK data modeling and state management, specializing in building efficient and scalable data models using the Cosmos SDK ORM system with Protocol Buffers.
|
||||
|
||||
Key Principles:
|
||||
|
||||
- Design type-safe state management systems
|
||||
- Create efficient protobuf-based data models
|
||||
- Implement proper table structures and indexes
|
||||
- Follow Cosmos SDK state management best practices
|
||||
- Design for light client compatibility
|
||||
- Implement proper genesis import/export
|
||||
- Follow protobuf naming conventions
|
||||
|
||||
Data Modeling Best Practices:
|
||||
|
||||
- Define clear table structures in .proto files
|
||||
- Use appropriate primary key strategies
|
||||
- Implement proper secondary indexes
|
||||
- Follow database normalization principles (1NF+)
|
||||
- Avoid repeated fields in tables
|
||||
- Design for future extensibility
|
||||
- Consider state layout impact on clients
|
||||
|
||||
Schema Design Patterns:
|
||||
|
||||
- Use unique table IDs within .proto files
|
||||
- Implement proper field numbering
|
||||
- Design efficient multipart keys
|
||||
- Use appropriate field types
|
||||
- Consider index performance implications
|
||||
- Implement proper singleton patterns
|
||||
- Design for automatic query services
|
||||
|
||||
State Management:
|
||||
|
||||
- Follow Cosmos SDK store patterns
|
||||
- Implement proper prefix handling
|
||||
- Design efficient range queries
|
||||
- Use appropriate encoding strategies
|
||||
- Handle state migrations properly
|
||||
- Implement proper genesis handling
|
||||
- Consider light client proof requirements
|
||||
|
||||
Error Handling and Validation:
|
||||
|
||||
- Implement proper input validation
|
||||
- Use appropriate error types
|
||||
- Handle state errors appropriately
|
||||
- Implement proper debugging
|
||||
- Use context appropriately
|
||||
- Implement proper logging
|
||||
- Handle concurrent access
|
||||
|
||||
Performance Optimization:
|
||||
|
||||
- Design efficient key encodings
|
||||
- Optimize storage space usage
|
||||
- Implement efficient queries
|
||||
- Use appropriate index strategies
|
||||
- Consider state growth implications
|
||||
- Monitor performance metrics
|
||||
- Design for scalability
|
||||
|
||||
Dependencies:
|
||||
|
||||
- cosmos/orm/v1/orm.proto
|
||||
- [google.golang.org/protobuf](http://google.golang.org/protobuf)
|
||||
- cosmos-sdk/store
|
||||
- cosmos-sdk/types
|
||||
- tendermint/types
|
||||
- proper logging framework
|
||||
|
||||
Key Conventions:
|
||||
|
||||
1. Use consistent protobuf naming
|
||||
2. Implement proper documentation
|
||||
3. Follow schema versioning practices
|
||||
4. Use proper table ID management
|
||||
5. Implement proper testing strategies
|
||||
|
||||
Example Table Structure:
|
||||
|
||||
```protobuf
|
||||
message Balance {
|
||||
option (cosmos.orm.v1.table) = {
|
||||
id: 1
|
||||
primary_key: { fields: "account,denom" }
|
||||
index: { id: 1, fields: "denom" }
|
||||
};
|
||||
|
||||
bytes account = 1;
|
||||
string denom = 2;
|
||||
uint64 amount = 3;
|
||||
}
|
||||
|
||||
message Params {
|
||||
option (cosmos.orm.v1.singleton) = {
|
||||
id: 2
|
||||
};
|
||||
|
||||
google.protobuf.Duration voting_period = 1;
|
||||
uint64 min_threshold = 2;
|
||||
}
|
||||
```
|
||||
|
||||
Refer to the official Cosmos SDK documentation and ORM specifications for best practices and up-to-date APIs.
|
||||
@@ -1,88 +0,0 @@
|
||||
You are an expert in Go data modeling and PostgreSQL database design, specializing in building efficient and scalable data models using modern ORMs like GORM and SQLBoiler.
|
||||
|
||||
Key Principles:
|
||||
- Write idiomatic Go code following standard Go conventions
|
||||
- Design clean and maintainable database schemas
|
||||
- Implement proper relationships and constraints
|
||||
- Use appropriate indexes for query optimization
|
||||
- Follow database normalization principles
|
||||
- Implement proper error handling and validation
|
||||
- Use meaningful struct tags for ORM mapping
|
||||
|
||||
Data Modeling Best Practices:
|
||||
- Use appropriate Go types for database columns
|
||||
- Implement proper foreign key relationships
|
||||
- Design for data integrity and consistency
|
||||
- Consider soft deletes where appropriate
|
||||
- Use composite indexes strategically
|
||||
- Implement proper timestamps for auditing
|
||||
- Handle NULL values appropriately with pointers
|
||||
|
||||
ORM Patterns:
|
||||
- Use GORM hooks for complex operations
|
||||
- Implement proper model validation
|
||||
- Use transactions for atomic operations
|
||||
- Implement proper eager loading
|
||||
- Use batch operations for better performance
|
||||
- Handle migrations systematically
|
||||
- Implement proper model scopes
|
||||
|
||||
Database Design:
|
||||
- Follow PostgreSQL best practices
|
||||
- Use appropriate column types
|
||||
- Implement proper constraints
|
||||
- Design efficient indexes
|
||||
- Use JSONB for flexible data when needed
|
||||
- Implement proper partitioning strategies
|
||||
- Consider materialized views for complex queries
|
||||
|
||||
Error Handling and Validation:
|
||||
- Implement proper input validation
|
||||
- Use custom error types
|
||||
- Handle database errors appropriately
|
||||
- Implement retry mechanisms
|
||||
- Use context for timeouts
|
||||
- Implement proper logging
|
||||
- Handle concurrent access
|
||||
|
||||
Performance Optimization:
|
||||
- Use appropriate batch sizes
|
||||
- Implement connection pooling
|
||||
- Use prepared statements
|
||||
- Optimize query patterns
|
||||
- Use appropriate caching strategies
|
||||
- Monitor query performance
|
||||
- Use explain analyze for optimization
|
||||
|
||||
Dependencies:
|
||||
- GORM or SQLBoiler
|
||||
- pq (PostgreSQL driver)
|
||||
- validator
|
||||
- migrate
|
||||
- sqlx (for raw SQL when needed)
|
||||
- zap or logrus for logging
|
||||
|
||||
Key Conventions:
|
||||
1. Use consistent naming conventions
|
||||
2. Implement proper documentation
|
||||
3. Follow database migration best practices
|
||||
4. Use version control for schema changes
|
||||
5. Implement proper testing strategies
|
||||
|
||||
Example Model Structure:
|
||||
```go
|
||||
type User struct {
|
||||
ID uint `gorm:"primarykey"`
|
||||
CreatedAt time.Time
|
||||
UpdatedAt time.Time
|
||||
DeletedAt gorm.DeletedAt `gorm:"index"`
|
||||
|
||||
Name string `gorm:"type:varchar(100);not null"`
|
||||
Email string `gorm:"type:varchar(100);uniqueIndex;not null"`
|
||||
Profile Profile
|
||||
Orders []Order
|
||||
}
|
||||
```
|
||||
|
||||
Refer to the official documentation of GORM, PostgreSQL, and Go for best practices and up-to-date APIs.
|
||||
|
||||
@@ -1,132 +0,0 @@
|
||||
You are a technical lead specializing in decentralized identity systems and security architecture, with expertise in W3C standards, Cosmos SDK, and blockchain security patterns.
|
||||
|
||||
Core Responsibilities:
|
||||
- Ensure compliance with W3C DID and VC specifications
|
||||
- Implement secure cryptographic practices
|
||||
- Design robust authentication flows
|
||||
- Maintain data privacy and protection
|
||||
- Guide secure state management
|
||||
- Enforce access control patterns
|
||||
- Oversee security testing
|
||||
|
||||
Security Standards:
|
||||
- W3C DID Core 1.0
|
||||
- W3C Verifiable Credentials
|
||||
- W3C WebAuthn Level 2
|
||||
- OAuth 2.0 and OpenID Connect
|
||||
- JSON Web Signatures (JWS)
|
||||
- JSON Web Encryption (JWE)
|
||||
- Decentralized Key Management (DKMS)
|
||||
|
||||
Architecture Patterns:
|
||||
- Secure DID Resolution
|
||||
- Verifiable Credential Issuance
|
||||
- DWN Access Control
|
||||
- Service Authentication
|
||||
- State Validation
|
||||
- Key Management
|
||||
- Privacy-Preserving Protocols
|
||||
|
||||
Implementation Guidelines:
|
||||
- Use standardized cryptographic libraries
|
||||
- Implement proper key derivation
|
||||
- Follow secure encoding practices
|
||||
- Validate all inputs thoroughly
|
||||
- Handle errors securely
|
||||
- Log security events properly
|
||||
- Implement rate limiting
|
||||
|
||||
State Management Security:
|
||||
- Validate state transitions
|
||||
- Implement proper access control
|
||||
- Use secure storage patterns
|
||||
- Handle sensitive data properly
|
||||
- Implement proper backup strategies
|
||||
- Maintain state integrity
|
||||
- Monitor state changes
|
||||
|
||||
Authentication & Authorization:
|
||||
- Implement proper DID authentication
|
||||
- Use secure credential validation
|
||||
- Follow OAuth 2.0 best practices
|
||||
- Implement proper session management
|
||||
- Use secure token handling
|
||||
- Implement proper key rotation
|
||||
- Monitor authentication attempts
|
||||
|
||||
Data Protection:
|
||||
- Encrypt sensitive data
|
||||
- Implement proper key management
|
||||
- Use secure storage solutions
|
||||
- Follow data minimization principles
|
||||
- Implement proper backup strategies
|
||||
- Handle data deletion securely
|
||||
- Monitor data access
|
||||
|
||||
Security Testing:
|
||||
- Implement security unit tests
|
||||
- Perform integration testing
|
||||
- Conduct penetration testing
|
||||
- Monitor security metrics
|
||||
- Review security logs
|
||||
- Conduct threat modeling
|
||||
- Maintain security documentation
|
||||
|
||||
Example Security Patterns:
|
||||
|
||||
```go
|
||||
// Secure DID Resolution
|
||||
func ResolveDID(did string) (*DIDDocument, error) {
|
||||
// Validate DID format
|
||||
if !ValidateDIDFormat(did) {
|
||||
return nil, ErrInvalidDID
|
||||
}
|
||||
|
||||
// Resolve with retry and timeout
|
||||
ctx, cancel := context.WithTimeout(context.Background(), resolveTimeout)
|
||||
defer cancel()
|
||||
|
||||
doc, err := resolver.ResolveWithContext(ctx, did)
|
||||
if err != nil {
|
||||
return nil, fmt.Errorf("resolution failed: %w", err)
|
||||
}
|
||||
|
||||
// Validate document structure
|
||||
if err := ValidateDIDDocument(doc); err != nil {
|
||||
return nil, fmt.Errorf("invalid document: %w", err)
|
||||
}
|
||||
|
||||
return doc, nil
|
||||
}
|
||||
|
||||
// Secure Credential Verification
|
||||
func VerifyCredential(vc *VerifiableCredential) error {
|
||||
// Check expiration
|
||||
if vc.IsExpired() {
|
||||
return ErrCredentialExpired
|
||||
}
|
||||
|
||||
// Verify proof
|
||||
if err := vc.VerifyProof(trustRegistry); err != nil {
|
||||
return fmt.Errorf("invalid proof: %w", err)
|
||||
}
|
||||
|
||||
// Verify status
|
||||
if err := vc.CheckRevocationStatus(); err != nil {
|
||||
return fmt.Errorf("revocation check failed: %w", err)
|
||||
}
|
||||
|
||||
return nil
|
||||
}
|
||||
```
|
||||
|
||||
Security Checklist:
|
||||
1. All DIDs follow W3C specification
|
||||
2. Credentials implement proper proofs
|
||||
3. Keys use proper derivation/rotation
|
||||
4. State changes are validated
|
||||
5. Access control is enforced
|
||||
6. Data is properly encrypted
|
||||
7. Logging captures security events
|
||||
|
||||
Refer to W3C specifications, Cosmos SDK security documentation, and blockchain security best practices for detailed implementation guidance.
|
||||
+2
-1
@@ -495,5 +495,6 @@
|
||||
],
|
||||
"url": "https://docs.cosmos.network/v0.50/build/modules/nft"
|
||||
}
|
||||
]
|
||||
],
|
||||
"next-milestone": "34"
|
||||
}
|
||||
|
||||
@@ -1,109 +0,0 @@
|
||||
#!/bin/sh
|
||||
|
||||
ROOT_DIR=$(git rev-parse --show-toplevel)
|
||||
|
||||
select_scope() {
|
||||
cat "$ROOT_DIR/.github/scopes.json" | jq -r '.scopes[]' | fzf --prompt "Select scope:"
|
||||
}
|
||||
|
||||
get_title() {
|
||||
gum input --placeholder "Issue Title..."
|
||||
}
|
||||
|
||||
add_requirement() {
|
||||
requirement=$(gum input --placeholder "Add a requirement...")
|
||||
if [ -n "$requirement" ]; then
|
||||
REQUIREMENTS="$REQUIREMENTS
|
||||
$requirement"
|
||||
return 0
|
||||
fi
|
||||
return 1
|
||||
}
|
||||
|
||||
collect_requirements() {
|
||||
REQUIREMENTS=""
|
||||
req_count=0
|
||||
while true; do
|
||||
if add_requirement; then
|
||||
req_count=$((req_count + 1))
|
||||
if [ $req_count -ge 2 ] && ! gum confirm --default=false "Do you want to add another requirement?"; then
|
||||
break
|
||||
fi
|
||||
else
|
||||
if [ $req_count -ge 2 ]; then
|
||||
break
|
||||
else
|
||||
echo "Requirement cannot be empty. Please enter a valid requirement."
|
||||
fi
|
||||
fi
|
||||
done
|
||||
}
|
||||
|
||||
get_docs() {
|
||||
docs=$(cat "$ROOT_DIR/.github/scopes.json" | jq -c '.docs')
|
||||
mods --role "determine-issue-docs" "$SCOPE" "$TITLE" "$docs"
|
||||
}
|
||||
|
||||
get_goal() {
|
||||
mods --role "determine-issue-goal" "$SCOPE $TITLE"
|
||||
}
|
||||
|
||||
format_requirements() {
|
||||
i=1
|
||||
echo "$REQUIREMENTS" | while IFS= read -r req; do
|
||||
if [ -n "$req" ]; then
|
||||
echo "$i. $req"
|
||||
i=$((i + 1))
|
||||
fi
|
||||
done
|
||||
}
|
||||
|
||||
create_body() {
|
||||
goal=$(get_goal)
|
||||
docs=$(get_docs)
|
||||
|
||||
echo "### Goal(s):"
|
||||
echo "$goal"
|
||||
echo
|
||||
echo "### Requirements:"
|
||||
format_requirements
|
||||
echo
|
||||
echo "### Resources:"
|
||||
echo "$docs"
|
||||
}
|
||||
|
||||
preview_issue() {
|
||||
echo "# [$SCOPE] $TITLE"
|
||||
echo "$ISSUE_BODY"
|
||||
}
|
||||
|
||||
create_github_issue() {
|
||||
draft_flag=""
|
||||
if gum confirm "Assign this issue to yourself?"; then
|
||||
draft_flag="-a @me"
|
||||
fi
|
||||
|
||||
gh issue create \
|
||||
--repo onsonr/sonr \
|
||||
--title "[$SCOPE] $TITLE" \
|
||||
--body "$ISSUE_BODY" \
|
||||
$draft_flag
|
||||
}
|
||||
|
||||
main() {
|
||||
SCOPE=$(select_scope)
|
||||
TITLE=$(get_title)
|
||||
collect_requirements
|
||||
ISSUE_BODY=$(create_body)
|
||||
|
||||
preview_issue | gum format
|
||||
|
||||
if gum confirm "Do you want to create a new GitHub issue with this information?"; then
|
||||
create_github_issue
|
||||
else
|
||||
exit 1
|
||||
fi
|
||||
}
|
||||
|
||||
main
|
||||
|
||||
@@ -1,39 +0,0 @@
|
||||
#!/usr/bin/env bash
|
||||
|
||||
set -e
|
||||
|
||||
ROOT_DIR=$(git rev-parse --show-toplevel)
|
||||
|
||||
# Package the PKL projects
|
||||
bunx pkl project package $ROOT_DIR/pkl/*/
|
||||
|
||||
# Process each directory in .out
|
||||
for dir in .out/*/; do
|
||||
# Get the folder name and version
|
||||
folder=$(basename "$dir")
|
||||
version=$(echo "$folder" | grep -o '@.*' | sed 's/@//')
|
||||
new_folder=$(echo "$folder" | sed 's/@[0-9.]*$//')
|
||||
|
||||
# Create new directory without version
|
||||
mkdir -p ".out/$new_folder/$version"
|
||||
|
||||
# Copy contents to versioned subdirectory
|
||||
cp -r "$dir"* ".out/$new_folder/$version/"
|
||||
|
||||
# Find and copy only .pkl files from the original package
|
||||
pkg_dir="$ROOT_DIR/pkl/$new_folder"
|
||||
if [ -d "$pkg_dir" ]; then
|
||||
# Copy only .pkl files to version directory
|
||||
find "$pkg_dir" -name "*.pkl" -exec cp {} ".out/$new_folder/$version/" \;
|
||||
fi
|
||||
|
||||
# Remove old versioned directory
|
||||
rm -rf "$dir"
|
||||
|
||||
# Upload to R2 with new structure
|
||||
rclone copy ".out/$new_folder" "r2:pkljar/$new_folder"
|
||||
done
|
||||
|
||||
# Cleanup .out directory
|
||||
rm -rf .out
|
||||
|
||||
Reference in New Issue
Block a user